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Prefatá 


Plecând de la ideea că orice sistem, subsistem sau aplicaţie informatică, ce implică 
lucrul cu volume mari de date, face apel la un mod sau altul de organizare a datelor si că de 
modul de organizare a datelor depinde în mare măsură performanţele soluţiei informatice. În 
acest context, În prezenta lucrare autorii tratează problematica bazelor de date ca formă 
superioară de organizare a datelor. 

Lucrarea începe prin prezentarea evoluţiei organizării datelor plecând de la formele 
cele mai simple până la cele mai complexe şi de actualitate. Sunt expuse cele două mari grupe 
de moduri de organizare a datelor si anume, în fişiere şi în baze de date. În prima grupă, se 
recurge la o sumară prezentare a organizării datelor în fişiere secvențiale, secvențiale 
indexate, fişiere cu organizare directă, relativă, partiţionate, multiindexate (multiliste sau 
multichei), inverse şi fişiere integrate ca formă intermediară de trecere la baze de date. 

Autorii au apreciat ca fiind de interes şi prezentarea organizării datelor în fişiere dintr- 
o serie de considerente de ordin teoretic şi practic. Pe de o parte, unele metode şi tehnici de 


_ organizare, acces si regăsire a datelor folosite în lucrul cu fişiere sunt întâlnite şi implementate 
_şi în tehnologia utilizării bazelor de date. Totodată, prin prezentarea diverselor tehnici și 


metode amintite, sporeşte iniţiativa şi intuiţia analiştilor şi programatorilor de a descoperi noi 
metode sau a le perfecționa pe cele existente. Mai mult, unele moduri de organizare a datelor 
în fişiere încă sc mai folosesc cu mare succes pentru anumite aplicaţii. 

ceea ce priveşte cea de a doua grupă de moduri de organizare a datelor, autorii 
recurg la prezentarea bazelor de date ca forme superioare și mai performante de organizare a 
datelor şi anume: baze de date relafionale, obiectuale, obiectual-relaţionale, multimedia, 
spaţiale, bazele de date distribuite, multidimensionale, depozitele de date si bazele de date on- 
line (baze de date Web). 

Lucrarea este realizată într-o abordare gradată a problematicii de referinţă în sensul că 
se porneste de la prezentarea organizării datelor în fişiere, apoi se trece la prezentarea într-o 
formă originală a succesiunii logice a conceptelor ce concură la definirea bazei de date. Se 
continuă cu tratarea specificului, avantajelor si dezavantajelor bazelor de date relaţionale 
comparativ cu organizarea datelor în fişiere. Urmează bazele de date orientate obiect cu 
precizarea specificului lor, avantajelor şi dezavantajelor acestora comparativ cu bazele de date 
relationale. Ținând seama de avantajele şi dezavantajele celor două modele de date, relagional 
şi obiectual, prin preluarea a ceea ce este mai bun de la fiecare s-a ajuns la modelul de baze de 
date obiectual- relational. Bazele de date multimedia si spaţiale sunt considerate şi tratate ca 
extensii ale modelelor relational şi obiectual. În mod asemănător, se continuă cu celelalte 
tipuri de baze de date ca fiind extensii ale precedentelor moduri de organizare. Totodată, pe 
parcursul întregii lucrări se recurge la exemplificări, scheme şi imagini sugestive. Apreciem 
că acest mod de prezentare oferă cititorului facilităţi sub aspectele parcurgerii, înțelegerii și 
insusirii problematicii abordate. Un spaţiu larg este rezervat precizărilor referitoare la 
proiectarea si implementarea diferitelor modele de date. Se definesc etapele de urmat si 
problemele de rezolvat. 

Având in vedere domeniul nelimitat de utilizare a bazelor de date si interesul crescând 
pentru acest mod de organizare a datelor, apreciem că lucrarea poate fi de un real folos 
elevilor, studenţilor, profesioniştilor IT, cum ar fi analişti sau proiectanți de sisteme 


informatice, programatori de aplicaţi, ingineri de sistem şi altor categorii de persoane 
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Capitolul 1 
Elemente de teoria bazelor de date 


1.1. Evoluţia organizării datelor 


Este cunoscut faptul că orice sistem, subsistem sau aplicaţie informatică ce implică un 
volum sporit de date, face apel la un mod sau altul de organizare a datelor. 

Prin organizarea datelor vom înţelege definirea, structurarea, ordonarea şi gruparea 
datelor în colecţii de date, precum si stabilirea legăturilor între acestea şi în cadrul elementelor 
colecţiei de date. 

Organizarea datelor a cunoscut o evoluție marcantă în timp, atât sub aspect teoretic cât 
şi practic, extinzându-se mult gama principiilor şi metodelor de structurare, stocare, regăsire şi 
gestiune a datelor, în concordanţă cu progresul din domeniile hardware şi software cât şi cu 
exigenţele tot mai ridicate și diversificate ale utilizatorilor. 

Evoluţia organizării datelor a însemnat un salt calitativ sub aspectul flexibilităţii in 
exploatare, a timpului de acces, a spaţiului de memorie, a protecției datelor etc. 

evoluția organizării datelor pot fi marcate anumite aspecte esenţiale care au permis 
realizarea salturilor calitative, acestea urmând a fi evidențiate pe etape. 

Prima etapă se referă la perioada dinainte de apariţia calculatoarelor din generaţia a 3-a 
(primul calculator din generația a 3-a a fost instalat în anul 1965) şi se caracterizează prin 
următoarele aspecte: 

— datele erau organizate în fişiere secvențiale, 

— structura logică coincidea cu structura fizică (figura 1.1) iar programatorul trebuia 

să descrie şi organizarea fizică a datelor pe suport. 


OPERATII DE VE 


ORGANIZARE LOGICĂ ORGANIZARE FIZICĂ 
Fig. 1.1 Etapa I-a de organizare a datelor 
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— mu se asigură independenţa programelor faţă de organizarea datelor; modificarea 
structurii datelor sau a dispozitivului de memorare implică şi rescrierea 
programelor, recompilarea şi testarea acestora în noile condiții; 

— redundanja mare între fişiere, deoarece acestea erau dedicate aplicaţiilor, chiar 
dacă unele date se regăseau în mai multe fişiere; 

— software-ul realiza numai operaţii simple de intrare/ieșire. 


Etapa a Il-a este marcată de apariţia dispozitivelor de memorare în acces direct (discuri 
magnetice) care permit atât accesul secvențial cát si direct la înregistrările unui fişier (figura 
12). 


Fig. 1.2. Etapa A-II de organizare a datelor 


Această etapă se caracterizează prin: 

— datele erau organizate sub forma unor fişiere secvențiale, indexat-secventiale, 
directe si prelucrarea se făcea în batch, on-line sau în timp real; 

— structura logică nu mai coincide cu structura fizică ca în prima etapă, iar 
organizarea fizică pe suport nu mai este făcută de programator, ci este realizată de 
componente specializate ale sistemului de operare — așa numitele metode de acces; 

— se asigură independența programelor faţă de unitatea de memorare (schimbarea 
unităţii de memorare nu implică modificarea programelor); 

— se menţine totuşi un grad de redundanţă ridicat; 

— accesul se face la nivel de înregistrare şi nu de câmp în cadrul înregistrării; 

— nuse realiza accesul după chei multiple; 

— dacă programatorul dorea realizarea unor fişiere cu legături trebuia să-şi 
programeze legăturile. 


Etapa a III-a a început prin anii 1970 şi este marcată de apariţia bazelor de date (figura 
1.3.). Elementele noi care apar în această etapă faţă de precedente sunt: 
— existența unui fond comun de date, pentru mai multe aplicaţii (baza de date), a 
cărui organizare fizică este independentă de programele de aplicaţii; 
— constituirea unor fişiere logice, funcţie de necesităţi, plecând de la baza de date; 
— accesul la date se face la nivel de câmp, sau grup; 
— scade redundanja, îi este permis accesul după chei multiple; 
— existenţa unor măsuri de protecţie si securitate a datelor, 


p 


— organizarea datelor este realizată de o componentă a software, cunoscută sub 
numele de dara management. 


„ORGANIZARE LOGICA 
D rdc i 
GESTIUNEA DATELOR (data management) 


ORGANIZARE FIZICĂ 


Fig. 1.3. Etapa a III-a de organizare a datelor 


Etapa a IV-a se caracterizează în primul rând prin asigurarea independenței logice si 
fizice a datelor faţă de programele de aplicaţie (figura 1.4.). 


Fig. 1.4. Etapa a IV-a de organizare a datelor 


Independenţa logică se realizează prin intermediul unui al 3-lea nivel de descriere a 
datelor (nivelul logic global) care se dope ete bazei de date. 
Administratorul bazei de date nu trebuie confundat cu proprietarul datelor. E] defineşte 
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structura înregistrărilor din baza de date, dar nu are acces a conținutul acestora, lucru permis 
numai proprietarului datelor. Orice modificare a structurii datelor se solicită de proprietar, 
administratorul bazei, singurul autorizat să facă acest lucru. 


- creşte gradul de protecție si securitate a datelor, 
- existenga unor fiiere inverse, care permit răspunsul rapid la anumite întrebări 
formulate de utilizatori, 
= existența unor limbaje de specialitate de: descriere, manipulare şi interogare 3 
bazei de date, precum şi pentru administrator. 
O prezentare mai analitică a evolufiei modurilor de organizare a datelor este redată în 
figura 1.5. unde semnificaţia notafiilor este: 


-FS fişiere cu organizarea secvenţială, 
-FSI fişiere secvențial indexate, 

-FR fişiere cu organizare relativă, 
-FOD fişiere cu organizare directă, 


fişiere integrate, 

-BDA baze de date arborescente sau ierarhice, 
-BDSR baze de date cu structuri de tip rejea, 
-BDR baze de date relaționale, 
-BDOO baze de date orientate obiect, 
-BDMM baze de date multimedia, 
- BDSP baze de date spaţiale, 
-DD depozite de date (Data Warehouse), 
-DM Data Mining, 
-BDMD baze de date multidimensionale, 
-BDWEB baze de date WEB (BD on-line) 
y mai există şi alte tipuri de baze de date, dintre care cele mai 

semnificative sunt cele distribuite 


Analizând evoluţia organizări datelor conform celor prezentate in figura 1.5 pot fi 
desprinse o serie de concluzii, astfel: 
= Exista dou mari grupe de moduri de organizare a datelor şi anume: organizarea 
datelor în fişiere şi respectiv în baze de date; 
-Atât fişierele cât si bazele de date pot fi de mai multe tipuri; 
- Un anumit mod de organizare a datelor nu exclude precedentele moduri de 
i , astfel încât in prezent se recurge atăt la organizarea datelor în fişiere 


date. 
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Nivel calitativ 


j 


Fig. 1.5. Evoluţia organizării datelor 
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— Fiecare mod de organizare a datelor prezintă avantaje şi dezavantaje. În general 
prin înlăturarea unor dezavantaje s-a reuşit un salt calitativ ajungându-se astfel la 
un alt mod de organizare a datelor; 

— Nu se poate face o delimitare exactă în timp a momentului apariţiei sau dispariţiei 
unui anumit mod de organizare a datelor; 

- BDMM şi BDSP sunt considerate ca extensii ale modelelor relational si obiectual; 

- Actualmente BDR deţin ponderea mare în domeniul aplicaţiilor economice însuși 
tendința este spre extinderea BDOO, 


1.2. Caracteristici generale a organizării datelor în 
fişiere 


În cele ce urmează vom recurge la o evidenjiere a celor mai semnificative aspecte 
referitoare la modul de organizare a datelor în fişiere. 


Definiţia fişierului: un fişier reprezintă o colecție de date omogene stocate pe un suport 
de memorie externă. 


- .. Un fişier conține o multitudine de înregistrări referitoare la un anumit domeniu de 
preocupare. Exemplul, informaţiile referitoare la Furnizori pot fi organizate într-un fişier, iar 
datele referitoare la un furnizor vor forma o înregistrare. 

—— Înregistrările pot fi privite la nivel logic si respectiv fizic. De aici se poate desprinde si o 
primă concluzie și anume cà, în situaţia organizării datelor în fișiere avem de a face cu două 
niveluri de referință si anume nivelul logic şi respectiv nivelul fizic. 

Nivelul logic sugerează gândirea analistului proiectantului cu privire la modul de 
organizare a datelor, Nivelului logic îi corespunde structura logică a fişierului. 

Prin structura logică se precizează denumirile de atribute/câmpuri cu privire la 
caracteristicile obiectelor ce urmează a fi organizate şi stocate în fişiere. 

Nivelul fizic sugerează suportul tehnic de memorie externă pe care vor fi stocate datele. 
Nivelului fizic ii corespunde structura fizică a fişierului şi reflectă modalitatea concretă in 
care vor fi stocate datele. Se spune ca avem de a face cu proiectarea spaţiului logic pe spaţiul 
fizic. De remarcat faptul că structura logică a descrierii datelor nu coincide cu structura fizică. 
La nivelul fizic o înregistrare conţine pe lângă datele efective descrise la nivelul logic şi o 
serie de alte informaţii auxiliare asociate fiecărei înregistrări. 

O altă caracteristică a fişierelor o constituie faptul că ele prezintă un grad sporit de 
redundanţă a datelor, ceea ce afectează performanţele de ordin fizic a acestora cu privire la 
spaţiul de memorie şi timpului necesar actualizărilor şi prelucrării lor pe ansamblul sistemului 
informatic ce face apel la organizarea datelor în fişiere. 

În cele ce urmează vom recurge la o sumară prezentare a diferitelor tipuri de fişiere. 


a) Fișierele cu organizare secvențială prezintă particularitatea înregistrărilor ce vor fi 
stocate pe suportul de memorie externá în succesiunea în care ele apar la intrare. 
Totuși, înregistrările pot fi sortate/ordonate crescător sau descrescător după valorile 
asociate unei anumite caracteristici/câmp atribut din structura logică a înregistrării. 
Fişierele cu organizare secvenjíalá prezintă avantaje şi respectiv dezavantaje. Ca 
avantaje precizăm: 
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— pot fi organizate pe orice tip de suport de memorie externă, 
- ocupă foarte bine spaţiul de memorie externă. 
Ca dezavantaj am putea preciza faptul că oferă doar accesul secvențial la înregistrări. 


b) Fişiere cu organizare secvențial indexate. 

Fişierele cu organizare secvențial indexate pot fi organizate numai pe discuri magnetice. 
Ele oferă accesul la înregistrări atât secvențial cât şi direct pe bază de indecsi. Indexarea se va 
face după cheia principală/primară a înregistrării. 

Într-o astfel de situaţie fişierele cu organizare secvențiale indexate presupun existența a 
două tipuri de fişiere, şi anume: 

— un fişier principal sau de bază şi 
— un fişier auxiliar care mai poartă denumirea de fişier de indecşi sau tabelă 
directoare. 

Fişierul principal va conține multitudinea înregistrărilor de date efective despre 
colectivitatea de referință (ex. despre furnizori), fiind ordonate crescător după valorile 
asociate atributului cu semnificaţie de cheie primară (exemplu codul furnizorului). 

« Fişierul de indecşi (la baza de date îl vom regăsi cu denumirea de Tabelă de indecşi) 
conține indecși în funcție de care se va realiza accesul direct la înregistrările conţinute de 
fişierul principal. 

_Un fişier secvențial indexat poate fi asociat cu o carte obişnuită, unde cuprinsul cărții ce 
conţine capitolele şi paragrafele cu precizarea paginilor la care se regăsesc în carte iar paginile 
numerotate ar reprezenta fişierul principal. 


«) Fişiere cu organizare relativă 
Fişierele cu organizare relativă prezintă două particularități şi anume, pe de o parte, 
faptul că înregistrările sunt reținute pe spaţiul de memorie externă în succesiunea în care se 
prezintă la intrare (deci secvențial) iar, pe de altă parte, înregistrările sunt numerotate de către 
sistem, in ordine crescătoare de la 1. În acest mod fiecare înregistrarea va avea un număr de 
înregistrare. 
Accesul la înregistrările fișierului poate fi secvențial sau pe baza numărului de realizare. 


d) Fişiere cu organizare directă 
Specificul fişierelor cu organizare directă constă în faptul că înregistrările vor fi stocate 
pe suportul de memorie externă (disc magnetic) pe baza unui algoritm de randomizare, prin 
care se va determina adresa fizică a fiecărei înregistrări ce urmează a fi stocată. 
Numărul algoritmilor de randomizare este nelimitat, fiecare programator îşi poate defini 
propriul său algoritm de randomizare, Un exemplu de algoritm de randomizare ar putea fi de 


NP NP 


— KP; semnifică valoarea cheii primare a înregistrării i, 
— NP reprezintă un număr prim prestabilit de către programator, 
- rest va reprezenta adresa fizică a înregistrări rii i. 


y În concordanță cu aplicarea unui astfel de algoritm fiecare înregistrare va avea o adresă 
fizică prestabilită, indiferent de succesiunea înregistrărilor la intrare. 


— 


De remarcat faptul că pentru accesarea (regisirea) înregistrărilor din fişier se aplică 
același algoritm de randomizare folosit la crearea fişierului. 


3 partiționate i reduse de date precum şi 
Fisierele j erau folosite pentru lucru cu volume e c 
Vent ca biblioteci de programe catalogate. Actualmente fișierele partilionate mai pot fi 


lucru cu biblioteci de programe. Y we 
mide acd este format din două tipuri de fişiere si anume: a 
- fiiere de bază stocate sub formi de parifi (fiecare fişier de bază apare 


adresa fizică a fiecărei partiţii. 
ntre sogestiv un fişier partitionat poate fi redat precum în figura 1.6. 


Tabela directoare : S 
[ Adresa partijiilor_| A | B xl 


| Parti ~ 
P: 


Parti 
// 


Fig. 1.6. Forma unui fişier partiţionat 
ifi ji T i i de prelucrare a 
icrele jionate oferă avantajul că permit reducerea timpului 1 a 
daelor De ER ca urmare a faptului că descrierea nu se pia i n ei 
partiţii (fişier) ci concomitent (o singură dată) pentru toate parti 
directoare. 


Itiindexate : 4 
N tata oferă accesul la înregistrări după mai multe chei secundare de 


O cheie secundară se defineşte de forma: 


K= AM 
ke: cheia secundară de regăsire, 
K, - reprezintă chei mea 
Ay - reprezintă un atribut ce fce parte din structura inregistrări logice, 
V, - valoarea asociată atributului 4 în funcţie de care se definește cheia secundară. 
Exe de chei secundare de regásire ar putea fi: < SĂ 
xemple de Cel o cheie secundar de regăsire a uurorstudenilor „Bucureşen 
Bucureştean = Domiciliu Bucureşti 
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— să se definească o cheie secundară de regásire a tuturor angajaţilor dintr-o societate 
comercială ce au profesia ECONOMIST. 

Cheile secundare de regăsire se definesc pentru a da un răspuns facil si a spori viteza de 
răspuns la întrebări prestabilite cu o frecvenţă mare de apariţie. 

Un fişier multiindexat este format din două tipuri de fişiere si anume: 

— fişierul principal sau de bază, 
— “un fişier auxiliar sau tabelă directoare. 

Fişierul principal apare ca un fişier secvențial însă cu înregistrările sortate în ordine 
următoare după valorile cheii primare, Totodată fiecare înregistrare conține pe lângă datele 
propriu-zise si două zone de memorie în care se va stoca adresa următoarei respectiv adresa 
precedentei înregistrări ce face parte din aceiaşi listă. În acest mod la nivelul fişierului pentru 
fiecare cheie secundară de acces se generează câte o listă dublu întâlnită. 

Exemplu, pentru o societate comercială ce are un număr considerabil de mare de 
angajaţi, o listă ar putea însemna Inlánfuirca înregistrărilor corespunzătoare tuturor angajaţilor 
ce au profesia economist. 

Fişierul auxiliar sau tabela directoare va conţine câte o înregistrare pentru fiecare cheie 
secundară de regăsire, ce va confine la rândul ei denumirea cheii secundare de regăsire și 
adresa primei înregistrări din fişierul de bază ce face parte din listă. Pentru exemplul anterior 
înregistrarea din tabela directoare ar conţine denumirea cheii ca fiind „Economist” iar adresa 
primei înregistrări din fișierul de bază ce face parte din aceiași listă va fi marca primului 
angajat ce are profesia Economist. 

Datorită faptului că în tabela directoare pot fi definite multiple chei secundare de 
regăsire cu indexul corespunzător iar în fişierul principal pentru fiecare index se va genera 
câte o listă de înregistrări, înseamnă că vom avea de a face cu multiple chei secundare, 
multipli indecsi si respectiv in fişierul de bază multiple liste. 

Deci, câte chei atâţia indecşi câţi indecsi atâtea liste, Tocmai de aici rezultă şi faptul că 
fişierele multiindexate mai poartă denumirea de fișiere multichei sau multiliste. In mod 
sugestiv, un fişier multiindexat este redat ca formă în figura 1.7. 


Tabela directoare 


Fişierul de bază 


- fiecare înregistrare din fişierul de bază este sugerată printr-un dreptunghi, 

— numărul de deasupra dreptunghiului reprezintă valoarea cheii primare a 
înregistrării (cheia primară putând fi de exemplu marca salariatului), 

— Kı ar putea fi „economist” cu lista din fişierul de bază ce ar 
include salariaţii ce au marca (100, 101, 104), 

— Kaar putea fi „strungar” cu lista 
„strungar”, cu mărcile (105, 125, 1110), 

- Ks ar putea fi „toxicitate” cu lista corespunzătoare tuturor salariaţilor ce lucrează 
în mediu toxic şi au marca (105, ...) etc., 

— se observă că anumite înregistrări participă doar la o singură listă (1000, 1001), 
altele participă la formarea mai multor liste (100, 105), situaţie cum ar fi cazul în 
care salariatul are profesia „strungar” si lucrează în mediu toxic și situaţia în care 
anumite înregistrări nu participă la formarea nici unei liste, Astfel de înregistrări ce 
nu se regăsesc în nici o listă nu înseamnă cà nu se justifică să fie păstrate în fişier, 
ele pot fi necesare pentru informări de alt tip ce nu implică regăsirea după chei 


tuturor salariaţilor ce au profesia 


Exploatarea unui fişier multiindexat poate fi realizată in serie si în paralel a listelor de 
înregistrări. 

Exploatarea în serie presupune următoarea succesiune logică de operaţii. Cu c 
secundară ce prezintă interes se intră în Tabela directoare şi se identifică adresa primei 
înregistrări din fişierul de bază ce îndeplineşte condiția predefinit prin cheia secundară. Cu 
cheia astfel identificată se intră cu acces direct în fişierul de bază şi se determină prima 
înregistrare, care apoi va fi prelucrată sau afişată. Din înregistrarea curentă se va prelua adresa 
următoarei înregistrări ce face parte din aceiași listă, cu care apoi se intră din nou în fişierul de 
bază cu acces direct si va fi regăsită a doua Înregistrare etc. 

Exploatarea listelor în paralel presupune exploatarea concomitentă a listelor după două 
sau mai multe criterii secundare de regăsire. De exemplu, listarea tuturor salariaților ce au 
profesia „strungar” si lucrează în mediu „toxic”. Într-o astfel de situaţie există şi algoritmi de 
optimizare a parcurgerii listelor. 


g) Fişiere cu organizare inversă 

Fișierele cu organizare inversă oferă si ele succesul la înregistrări după mai multe chei 
secundare de regăsire. Cheile secundare de regăsire având aceeași semnificaţie precum în 
cazul fişierelor cu organizare multiindexată. 

Un fişier cu organizare inversă la fel ca şi în cazul precedent este format din două tipuri 
de fişiere, un fişier principal sau de bază şi unul secundar (figura 1.8). 

Fişierul principal apare ca un fişier obișnuit secvențial cu înregistrări sortate sau 


nesortate. 
Fişierul secundar este format dintr-un şir de bili, câte un bit corespunzător fiecărei 
Pentru fiecare cheie secundară de regăsire se generează câte un astfel de sir de biţi. 
Iniţial toţi biții sunt incrementați cu valoarea zero. Ulterior, cu ocazia încărcării 
fişierului principal cu înregistrări se va testa dacă înregistrarea curentă îndeplineşte sau nu 
condiţia prestabilită prin specificarea cheii secundare de regăsire. Dacă da, bitul corespunzător 
înregistrării curente va fi poziţionat pe 1, altfel va rămâne pe zero. 
Exploatarea unui fişier cu organizare inversă se va face astfel: se activează şirul de biţi 
apoi se procedează la explorarea acestuia in mod secvențial. 
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În momentul în care a fost identificat un bit având valoarea 1 se va recurge 
> at ere E la 
determinarea cardinalităţii acestuia (al câtelea bit este în cadrul șirului de biţi). 


Fig. 1.8. Fişiere inverse 


Pe baza cardinalitlfi bitului se va proceda la determinarea adresei relative a inregistrürii 
din fişierul principal corespunzătoare bitului curent, conform următoarei formule: 


ARI, = Aj D(N,-D 
unde; 
— ARÍ, este adresa relativă a înregistrării corespunzătoare cardinalităţii bitului curent, 
— Ao reprezintă adresa relativă de la care începe încărcarea fișierului principal, 
- D reprezintă deplasarea (lungimea înregistrării), 
— N,reprezintà cardinalitatea bitului. 


Cu adresa astfel determinată se va intra cu acces direct în fişierul de bază/ princij 
vs va Meilen dese ral ns fa Aaaa D A. etl 
socio aie e ifi va continua în același mod. 

E le avantaj a fol. fişierelor inverse îl constituie faptul că, pe lângă posibilitatea 
Sori a rias ATED Dale cât de gta de on liar roi van 
cererile utilizatorilor datorită faptului că accesul la i i 
haier înregistrări pe bază de adresă relativă 


h) Fişiere integrate 

Fişierele integrate mai poartă denumirea de fişiere cu legături. Particularitatea acestora 
constă în faptul că structura datelor era separată de datele efective. Structura era definită şi 
e afr spe TO te fee deu s pam deal legi. To 

ier separ t : ierele de date se puteau defini legături. Tocmai 

de la această particularitate, fişierele integrate mai purtau denumirea de fişiere înlănguite iar 
pentru gestiünea acestora existau pachete software speciale, cum ar fi BOMP, PICS, SCF ete. 

„Fișierele integrate marchează, prin particularitljile acestora, trecerea de la modelul de 
organizare a datelor în fişiere la modelul bazelor de date. 

Remarcá, Motivele pentru care s-a recurs la prezentarea organizării datelor în fişiere 
sunt două şi anume: 


_ anumite moduri de organizare a datelor în fişiere încă sunt de actualitate în sensul că 
se mai folosesc, z p Iiis: E 6 

- filozofia şi anumite tehnici de organizare a datelor în fişiere, cum organizarea 
datelor în fişiere relative, multiindexate, inverse si integrate le regăsim implementate şi la 
nivelul Bazelor de date. 


1.3. Concepte utilizate în definirea bazelor de date 


i i i ice si: subsistem sau aplicație 

Aşa după cum s-a mai precizat anterior, orice sistem, 
informatici ce implică Iurul cu volume mari de date face apel la un mod smu altul de 
organizare a datelor pe un anumit suport de memorie extemă. De modul spe 
datelor depinde în mare măsură performanțele sistemului „sub aspectele eco 
completitudinii cerinţelor informaţionale ale utilizatorilor, vitezei de răspuns a sistemului la 
solicitările utilizatorilor, facilităţilor de stocare, actualizare şi exploatare a datelor etc. - 

Tn cadrul modurilor de organizare a datelor, bazele de date reprezintă forma uj d 
performantă de organizare a datelor, satisfăcând cerințele amintite. Chiar mai m A 
contribuie la simplificarea si raționalizarea circuitelor şi fluxurilor informaţionale prin n l 
că bazele de date apar ca o sursă unică de informare la care vin datele din toate direcțiile şi 

leacă informațiile către toți utilizatorii . 

c In acest context, în cele ce urmează ne propunem să prezentăm sponi care duc la 
definirea bazei de date, precum si o serie de alte aspecte legate. de baze de date. - 

În elucidarea conceptului de bază de date considerăm necesar a se pleca de 
abordarea într-o succesiune logică a elementelor ce concură la definirea acestui concept. 
Astfel se va pleca de la definirea conceptelor de caracteristică, familie de caracteristici, 
proprietăți si relaţii dintre acestea, colecție de date şi baze de date. În figura 1.9 se sugerează 
succesiunea logică de abordare a acestor elemente. 


DOMENIUL CONCEPTUAL 


i caracteristici s HE 
Fig. 1.9. Succesiunea logică a elementelor ce concură la definirea conceptului 
de baze de date 
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1.3.1.Conceptul de caracteristică si familie de caracteristici 


Descrierea mulțimii entităţilor reale sau abstracte ale unui domeniu semantic se 
realizează cu ajutorul unei serii de caracteristici (C, i =1,n). În acest context caracteristica 
defineşte un aspect sau o latură a unui obiect din mulțimea respectivă. Deci, caracteristica la 
modul general are semnificația de atribut sau câmp prin care se descriu obiectele din mediul 
înconjurător. 
O mulţime de caracteristici e: mt caracteristici A şi se notează astfel: 
Asf jien 


Exemplu: 
PERSOANA- (NUME, PRENUME, SEX, STARE. CIVILĂ, FUNCŢIE, ADRESA, ......) 

unde, fiecare element dintre acolade reprezintă o caracteristică ce concură la descrierea unei 
PERSOANE. 


Elementele unei caracteristici sunt valorile (darele) corespunzătoare acesteia, Fiecărci 
caracteristici C i se asociază o mulţime de valori x; mulțime notată cu X si care constituie 
domeniul de valori pentru acea caracteristică. Familia având n caracteristici vor exista n 
mulțimi de valori si deci n domenii. 


Exemplu: 
CULOARE-AUTOMOBIL =(roșu, alb, galben, ..... portocaliu) 


unde, CULOARE-AUTOMOBIL are semnificaţia de caracteristică a automobilului 


(constituant) iar culorile roşu, alb, galben, .... reprezintă date/valori făcând parte din - 


domeniul culorilor. La modul general, domeniul culorilor va conţine ca valori multitudinea 
culorilor din paleta de culori. 

De remarcat faptul că, pot exista frecvente situaţii în care valorile asociate mai multor 
caracteristici fac parte dintr-un acelaşi domeniu. Exemplu, într-o familie de caracteristici 
(atribute) referitoare la descrierea unei Persoane ar putea exista atribute de forma: localitatea 
natală, domiciliul stabil, localitatea unde lucrează acea persoană. Intr-o astfel de situație, 
fiecare caracteristică va lua valori din cadrul aceluiași domeniu şi anume cel al “localităţilor”. 
Acesta include multitudinea “Denumirilor” de localităţi. Sau un alt exemplu, culoarea 
ochilor, culorile drapelului, culoarea creionului, etc. Toate aceste caracteristici sunt diferite ca 
semnificaţie însă toate iau valori ce fac parte din acelaşi domeniu. 

Pentru a se arăta că o dată aparţine sau nu mulțimii de valori (Xi) corespunzătoare 
caracteristicii C, se va scrie: xy e X, şi respectiv xy e X; i, j=1...n 


1.3.2.Conceptul de colecţie de date 
Fiind dată o familie de caracteristici de forma: 
N= {CCC} 
„Este de menționat faptul că între caracteristicile familiei A nu s-a precizat nici o relație 


de ordine. Pentru a imprima o anumită relație de ordine între aceste caracteristici şi a obține o 
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Capitolul 1 
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informatie cu un anumit sens, în concordanţă cu satisfacerea anumitor cerințe informaţionale 
necesare diferitelor categorii de utilizatori, asupra acestei familii A se poate aplica unul sau 
mai multe predicate P. Prin predicat înțelegând o mulțime de reguli (proprietăţi) cu ajutorul 
cărora se vor selecta numai acele combinaţii de C, cu xy e C, care îndeplinesc proprietăţile 
prestabilite ca fiind adevărate. i 

Se obține astfel o submulțime de caracteristici cu o anumită semnificaţie pe care o 
vom numi colecţie de date (K), de forma: 


K = P (A); w 2 
unde, w semnifică unul din mulțimea predicatelor ce se aplică asupra familiei 
K, astfel obținută poate apare astfel: 


K, = (Cuc, 


iar colecția 


Cn} 


unde msn. 
Deci, un predicat P este o proprietate asociată colecţiei de date K, dacă v re 7 atunci 
P[K(t)] = Adeváratà. 


Fiind dat un predicat P si un n-tuplu ordonat xy, de forma : 


ERT X; Xu Xis 
"Xs Xu Xn 

x» xs Xs 

Xm Xm Xes A mm rox Xn 


se poate defini relația n-ară R asociată predicatului P, astfel: 
R={( X14, 2313 Xi) : P [Gt Xi213 Xi] 7Adevárat) 


unde xpe X, i=1,2,...„n şi P [&xj1, X12.X13.-.- Xin)] reprezintă evaluarea predicatului. 


Exemplu: Fie familia de caracteristici à referitoare la descrierea persoanelor, de forma: 
A=(CNP, NUME. PERSOANĂ, VÂRSTA, PROFESIE, „LOC_MUNCĂ, NUME_COPIL, ....) 
Considerăm relația R de ordinul doi definită astfel: 
R=((NUME. PERSOANĂ, NUME. COPIL): P[(nume. persoand, nume copil)] = Adevărat) 
unde P defineşte regula prin care unei anumite persoane să i se asocieze numele copiilor ce îi 


aparţin. In mod asemânător pot fi aplicate o serie de alte reguli asupra familiei 2. obținând alte 
submultimi de caracteristici (alte colecţii de date). 


În situaţia in care urmărirea evoluției în timp a întregii colecţii de date prezintă interes, 
acesteia i se poate asocia o variabilă T care defineşte un decalaj al timpului în intervale 
discrete: 


T= (ts tj 
ceea ce înseamnă că in timp colecţia de 


(tr), Kid, Kt), sss Kta) 
Exemple privind evoluţia în timp a unei colecţii de date pot fi urmărite în capitolul 
“Depozite de date." 
Precizăm faptul că între colecţii de date sau intre caracteristicile unei aceleași colecții 
pot fi definite o serie de relații. Relaţia va avea semnificaţie de raport, legătură, asociere sau 
corespondenţa din limbajul curent. In acest context relația poate fi definită matematic astfel: 


Fie K; si Ky două colecţii de date. Numim corespondență (legătură) de la colecția de 
date K; la colecţia K un triplet O = (K,, G, K2), unde G este o submulțime a lui Kix K3, 
Submulfimea G se numeşte graficul corespondenjei. 


Într-o astfel de situație, fiind dată o colecţie K =/C, | ie N} sau mai multe colecţii, 
între caracteristicile acesteia sau între colecţii de date se pot stabili o multitudine de tipuri de 
relaţii : binare, ternare, ..., n-are, de echivalență, de ordine, de apartenenţă etc. Aceste relaţii 
se caracterizează printr-o serie de proprietăţi, dintre care cele mai semnificative şi cu 
aplicabilitate mai mare in teoria bazelor de date sunt cele de reflexivitate, simetric, 
tranzitivitate şi antisimetrie. I 

In continuare se va face o scurtă prezentare a unora dintre principalele tipuri de relaţii. 


a) Relaţii binare. Se numeşte relație binară între valorile a două colecţii de date K; si Kz 
sau între caracteristicile aceleași colecţii, o submulțime a produsului cartezian X; x X; 
ce satisface o anumită relație R, unde X; este domeniul valorilor caracteristicii C; e K), 
iar X; este domeniul valorilor caracteristici C; e Kz 
Valorile asociate prin relaţie sunt atunci acele elemente xy şi x», pentru care (xj, € Xj, 
xx € X) e R. Notánd cu R simbolul de relaţie, se va scrie: x; R x» pentru arăta că elementele 
xy, € X, $i xa € X; sunt asociate prin relația R 
In mod analog, se defineşte relaţia de ordin n între n caracteristici ale unei colecţii K 
sau între mai multe colecţii ca fiind o parte a produsului cartezian dintre valorile acestor 
caracteristici, astfel: 


Re Xix Xix X, sau TIX, île. 


“Elementele din cadrul unei relații n-are formează un n-tuplu ordonat de forma: 
(a, Xa, Xia, Xi) 


unde xy € X; , pentru orice valoare a lui i=1,2,....„n. Elementele se vor numai asociate relaţiei 
R atunci când (xj; X12, «+s xi) € R- 


Determinarea părţii de produs cartezian se poate realiza in două moduri: 
— prin enumerarea elementelor produsului cartezian ce fac parte din relația n-ară; 
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— prin utilizarea unui predicat P care să realizeze selectarea produsului cartezian. 


ateu topo o te 

Sei et de dio etiteare la activata de PERSONAL “a fina în același 

- "4n bază de date referitoare la activitatea FINANCIAR CONTABILĂ “conturile 

- EI i i OBECINE DE VEST deese tme 

punere în ; s » E. 

Find toca e cu el cei de de cu plur ca 

prin această relație se numesc echivalente. Mai multe tupluri echivalente formează o clasă de 
SM cu, don da citea poa i data: 


h te clasă de 
Fiind dată o relație de echivalență R în mulțimea M şi un element x € M, se mumeş 
echivalență Cx, mulțimea valorilor x şi y astfel ca x R y, adică C, =] xRy). 


Toate aceste tij de relaţii stau la baza organizării şi prelucrării automate a ər 
In faza de i "i rare à color de date, relie sunt mare, in geneal, prin 
punctatori logici sau fizici, prin chei sau alte elemente din structura logică sau a 
ce structurii logice sau virtuale a colecţiilor de date, relaţiile (legăturile) cele 
mai frecvente sunt: É a 
= ii de ti inte/proprietar), prin care se stabilesc legăturile dintre o 
caute Td) PARINTE şi toate înregistrările (liniile/rândurile) ce 
aparțin acesteia ( FIU/COPIL/MEMBER) ; AEN , 
- relații de tip NEXT (următorul), care oferă posibilitatea stabilirii de legături între 
tuplurile unei colecții de forma “legătura la următorul tuplu"; - zon 
- relații de tip PRIOR (precedentul), oferă posibilitatea stabilirii de legături 
tuplurile unei colecţii de forma inversă celor de tip NEXT, adică legătură 
Nhu. a Xu * 
acestor tij i de legături pot fi proiectate colecții cu înregistrări înlânţuite sau 
se pode plc e TOER, Viti 0 ui sm ficio d volei da dite. 3 
In faza de prelucrare a datelor, pe baza relațiilor amintite se pot efectua o serie de operaţii 
cum ar fi: operaţii de sortare (ordonare), interclasare, diferența a două colecții de 
produsul a două colecţii de date, proiecția unei colecţii de date etc. operaţii ce vor 
prezentate in capitolul “Baze de date relaţionale”. x 
Pe baza acestor elemente, se poste da o definiție mai completă unei colecţii de date ca 
fiind formată din următoarele componente: 
— familie de caracteristici A = (Caps 912,...,n; r 
— o suită temporală T = {y | care defineşte un decalaj al timpului în 


intervale discrete; 
— un predicat P aplicat asupra familiei A; 
— afectarea la fiecare moment 1, a unei relații n-are simetrice de spațiu de definire 


(Ci, Cs... C, asociată predicatului P. 


atj 
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Se va conveni ca evoluția colecției de date în timp să fie înţeleasă în mod implicit, iar 
specificarea explicită a timpului să se facă numai în cazurile în care acest lucru se impune. 

Colecţiile de date pot fi privite la nivel logic, virtual şi fizic, corespunzător celor trei 
niveluri de organizare a datelor în cu propunerea CODASYL (a se vedea 
nivelurile de organizare a datelor în baze de date) 

Pentru a distinge noțiunea de colecție de date la nivel logic, virtual şi fizic, într-o 
acceptiune mai largă, la nivel fizic vom spune că avem de a face cu realizări de colecţii de 
date. 


Numărul de caracteristici defineşte gradul/ordinul colecției n 


Domeniu X; eC; 


Fig.1.10. Sinteza elementelor ce definesc colecţia de date 


În figura 1.10. sunt prezentate elementele ce concură la definirea colecţiei de date. 
Pentru exemplul de faţă, predicatul P poate consta tocmai din enumerarea caracteristicilor 
colecţiei. Multitudinea caracteristicilor determină gradul colecției şi totodată ele constituie 
spaţiul de definire al colecţiei de date. 

O linie din cadrul colecţiei defineşte un tuplu sau înregistrare. Multitudinea tuplurilor 
unei colecții determină cardinalitatea colecției. Colecţia de date din figura 1.10 este de gradul 
n si cardinalitate m. 

Cerinţele de ordin practic impun ca fiecare tuplu dintr-o colecţie de date să poată fi 
identificat în mod unic printr-o anumită caracteristică. Din acest considerent, cu ocazia 
definirii structurii logice a colecției de date, din mulțimea caracteristicilor/atribulelor se va 
alege o anumită caracteristică prin ale cărei valori să permită identificarea unică a oricârui 
tuplu. O astfel de caracteristică va purta denumirea de cheie primară a colecției de date si este 
supusă restricției de unicitate. 

Definiţia cheii primare poate fi formulată astfel: 


Fiind dată o colecție de date K definită prin mulțimea caracteristicilor {C,, 

C; C,,.... C, ) gi o submulțime de caracteristici Y definită prin(C,, C, C,,...,C,) . unde 

YeK iar msn. Se spune că Y reprezintă cheia primară a colecției K dacă se bucură de 

Proprietatea de a permite identificarea unică a oricărui tuplu şi dacă nu există o altă 
Z care să se bucure de aceiași proprietate. 


Observaţie : în practică nu este exclus ca în definirea unei colecţii de date să existe 
două sau mai multe atribute prin ale căror valori să se poată identifica în mod unic oricare 
tuplu . Într-o astfel de situaţie se spune că avem de-a face cu atribute candidate la cheia 
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primară. Criteriul de alegere a cheii primare dintre mai multe atribute candidate il constituie 
minimalitatea lungimii cheii. Exemplu, presupunem o colecţie de date referitoare la Angajaţii. | 
unci societăți comerciale, definită prin caracteristicile: 


„ CNP} 


ANGAJAT= (marco, nume, profesia, funcția, data-naşteri, 
unde, marca este formată din 4 cifre, iar CNP din 13 cifre. 


Identificarea unică a oricărui angajat se poate face atât prin marca cât si prin CNP; 
deci avem două caracteristici (atribute) candidate la cheia primară. Aplicând criteriul 
minimalităţii lungimii cheii primare se va alege cheie primară atributul marca, fiind format 
doar din patru caractere; desigur există şi excepţii de la aplicarea acestui criteriu. 

Opus minimalităţii lungimii cheii primare avem de-a face cu maximalitatea lungimii 
cheii, situaţie în care identificarea unică a oricărui tuplu poate fi realizată şi prin precizarea 
valorilor corespunzătoare tuturor caracteristicilor prin care se defineşte structura logică a 
colecţiei de date însă, în practică nu se foloseşte. 

Colecţia de date se regăseşte sub diferite denumiri: fişier, în cazul organizării clasice a 
datelor; entitate şi domeniu, în concepția bazelor de date cu structuri arborescente si reţea; 
tabel, relaţie, viziune (VIEW) sau "cluster" (CLUSTER), în concepția bazelor de date 
relafionale; clasa de obiecte în concepţia bazelor de date orientate obiect. 


1.4. Conceptul de bază de date 


Una sau mai multe colecţii de date K, aflate în interdependență, împreună cu 
descrierea datelor şi a relaţiilor dintre ele formează o bază de date (B), adică: 


Be (Ka Ko Kon 1232. 


Apreciem că baza de date, astfel formulată, trebuie să îndeplinească următoarele 
condiţii: 
a. structura bazei de date (SB) trebuie astfel concepută încât să asigure informaţiile 
necesare si suficiente pentru satisfacerea cerințelor de informare (CI) şi decizie ale 
utilizatorilor finali: 


VE, 


unde : V — volumul datelor asociate structurii bazei de date şi respectiv cerințelor 
informaţionale (CI). 


b. să permită accesul rapid la informaţiile stocate în bază: 
[in] S(T, Ne) 
unde: 
T - reprezintă timpul de căutare-răspuns a sistemului pentru efectuarea unei 
aplicații; 
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Nac - reprezintă numărul de accese la baza de date. 


c. să prezinte o redundanță minimă şi controlată a datelor stocate. Prin redundanja 

datelor vom înţelege regăsirea unei aceleaşi caracteristici (atribut) în două sau mai 
multe colecții de date. 
Prezența redundanţei datelor în cadrul bazei de date generează o serie de anomalii de 
ordin logic care afectează performanțele de ordin fizic a bazei de date. Din aceste 
considerente este de dorit ca, pe cât posibil, redundanța să fie înlăturată. Insă, din 
anumite considerente de ordin practic uneori se acceptă un anumit grad de redundanță 
a datelor. Este de dorit ca redundanfa să fie minimă. Intr-o astfel de situaţie, 
redundanța se va exprima prin intersecția cardinalității informaţiilor colecţiilor de date 
Kaca fiind minimă: 


card (OKu) = minimă, w-12,....n 


Acceptarea unui anumit grad de redundanfá impune cu necesitate instituirea unui 
control automat asupra redundanţei. 

Prin control automat asupra redundanței datelor se urmăreşte asigurarea coerenfei 
bazei de date. 

Prin coerenţa bazei de date se va înţelege faptul că atributele/caracteristicile acceptate 
a fi redundante trebuie să aibă aceiaşi valoare sau nivel de indicator. 


controlul redundantei 


Nr.-matricol 


Fig. 1.11. Redundanfa datelor 


P 


Exemplu: 


1 (figura 1.11): 
astfel My à 
E inând informaţii generale despre studenți; a 
= eds aida informaţii despre notele studenţilor pe durata anilor de 
im z < 
- STUD TAXE conţinând informaţii despre taxele de şcolarizare ale studenţilor cu 
taxă. 


“Totodată, presupunem că din anumite considerente de ordin practic se acceptă ca 
atributul Adresa studentului să se regăsească în toate cele trei colecţii de date. 

Într-o astfel de situaţie va trebui să instituim control automat (prin program) asupra 
redundanjei, astfel încât atunci când se zile ien e cu valoare 

i efectueze concomitent în toate cele trei colec ă 
E ae paie tta de ios cce aspecte, indie Realul cu baze de date se spune cá 
redundant minimă si controlată a datelor. A 

pie zi dec de prier fi efectuată prin diverse canale oferite de programe de 
aplicaţie, limbaje de manipulare (procedurale sau neprocedurale) autonome, interfeţe cu 
limbaj i gramare şi/sau aplicaţii de uz general etc. — 
Vero etic a im de date precum si relaţiile dintre colecţiile ce compun 

date sunt prezentate în mod sugestiv în figura 1.12. s im 
bcn Mn de date implică existența unui SGBD ca mediator între utilizatori, 

là şi baza de date fizică. : 
laii 1.12 se sugerează baza de date fizică stocată pe suport magnetic, dopati 
din colecţii de date interdependente şi/sau Piu ce re ete d € pneu E boe 
, K4 şi K5) sau colecţii independente (K6). Utili acţione 

iz) és sistemului de gestiune a bazei de date (GG) prin agnis xu decise 
de aplicaţie (P1, P2, P3 şi P4) sau direct, prin intermediul limbajelor ita t 
pes re aS la baza de date poate fi realizat local sau la ss pei ferien 
on-line, calculatoare personale, calculatoare independent nie sau rețele d o 
Rezultatul interogărilor utilizatorului poate fi vizualizat, listat, stocat în fişiere, transmis la 
distanţă etc. 


o bază de date la nivelul unei Facultăţi, formată din trei colecţii de date, 


sistemul de 


= p EN 


Ex 1.12. Exploatarea bazei de date 


1.5. Conceptul de sistem de baze de date 


În paragraful anterior s-a definit conceptul de bază de date si am mai putea adăuga 
faptul că ea poate fi asociată cu un depozit sau un container (instalat pe un calculator în care 
se introduc şi se stochează date ce prezintă interes şi respectiv sunt extrase date în 
concordanţă cu cerinţele utilizatorilor). Însă, trebuie precizat faptul că baza de date nu se 
găseşte sau nu poate funcţiona la modul izolat ci se regăseşte încadrată într-un anumit mediu, 
cooperând cu o serie de alte componente (elemente). Dintre componentele cu care 
interacționează baza de date, enumerăm: 

- componentele hardware ale sistemului de calcul (calculatorul propriu-zis) pe care 
urmează a fi instalată baza d date; 

~ sistemul de gestiune a bazei de date (SGDB), care reprezintă software-ul propriu-zis 
al bazei de date. Fără un SGDB corespunzător, baza de date nu ar putea funcționa, astfel încât 
ea nu s-ar justifica ca existență; 

- utilizatorii bazei de date. Aceştia pot fi grupaţi în trei categorii, astfel: utilizatori 
finali (beneficiarii bazei de date ), programatorii de aplicaţii şi administratorul bazei de date. 
Despre toate aceste componente vom găsi detalii pe parcursul întregii cărți. 

În acest context, se poate spune că un sistem de baze de date reprezintă baza de date 
împreună cu multitudinea componentelor cu care interacționează. Acest aspect este sugerat 
în figura 1.12. 


1.6. Baze de date centralizate şi distribuite _ 


Vom considera o bază de date B definită conform celor expuse în $1.3.: 


B= (Ki Kyr Kd 


I1212,...,5. 

şi o mulţime de calculatoare interconectate formând o rețea R: 
RN Na LN) jeh2..m 

unde N, reprezintă nodurile rețelei de calculatoare. 


Fiecare colecţie K, este formată dintr-o mulțime de atribute (câmpuri, coloane) 
Ki = (A, Aas... Aah k=12..n şi are asociată o mulțime de date (linii, rânduri, 
Înregistrări). O linie din mulţimea datelor este reprezentată ca o asociere a valorilor pentru 

atribut din colecție. 

În funcție de modul în care sunt stocate colecțiile (și/sau datele asociate acestora) care 
formează baza de date aceasta poate fi: 

~ Centralizatá, în cazul în care totalitatea colecţiilor care formează baza de date sunt 
memorate pe un singur calculator. Dacă calculatorul este inclus într-o rețea de 
Calculatoare atunci baza de date poate fi considerată şi bază de date locală; 
Distribuită, în cazul in care colecţiile care compun baza de date (cel puţin una) sunt 
tate, iar fragmentele sunt stocate în nodurile unei rețele de calculatoare R. 
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În context distribuit baza de date este văzută ca o mulţime de partiții P, P,,..., P, cu 
d « m, unde o partiție P, corespunzătoare nodului N, este o submulțime a bazei de date B, 
adică P, c (X,, Ks- K,...],, cu d 22. În funcţie de modul în care părțile care compun 
baza de date sunt disjuncte sau nu baza de date va fi: 

— integral neduplicată (toate părțile componente sunt disjuncte); 

— parțial duplicată (există o submulțime de părți care nu sunt disjuncte); 

— total duplicată (fiecare parte componentă, stocată pe un calculator din rețea, nu 

este disjunctă cel puţin cu o parte aflată în alt nod al rețelei). 

În ambele cazuri, utilizatorul obişnuit are acces şi "vede" baza de date conform celor 
expuse în paragrafele anterioare. 

Noţiunea de distribuție va fi tratată pe larg în capitolul referitor la baze de date 
distribuite. 


1.7. Niveluri de organizare a datelor în baze de date 


Spre deosebire de sistemele clasice de prelucrare automată a datelor, unde 
organizarea datelor în fişiere presupunea două niveluri de referință (nivelul logic si nivelul 
fizic), în cazul bazelor de date se distinge şi un al treilea nivel de structurare a datelor şi 
anume, nivelul virtual (nivel conceptual). In scopul simplificării prezentării (si pentru 
păstrarea legăturii cu organizarea datelor in fişiere) pentru nivelul fizic, virtual (conceptual) 
şi logic (extern) de organizare a structurii bazei de date, vom utiliza denumirea prescurtată 
de structură fizică, virtuală (sau conceptuală) si respectiv logică (externă) a bazei de date. 

Structura logică (nivel extern) a datelor se referă la forma în care fiecare utilizator 
vede structurarea datelor în funcție de aplicaţia cu care lucrează sau în funcţie de resursele 
de date pe care administratorul bazei de date i le-a pus la dispoziție ca structură externă 
(subschema bazei de date la care are drepturi de acces). 

Structura fizică se referă la modul de memorare si structurare a datelor pe suportul 
fizic. Structura fizică a suportului de memorare admisă de către un SGBD, permite în general 
următoarele niveluri de referință: volum magnetic, cilindru, pista, sector, bloc, octet si bit. 

Structura virtuală se referă la definirea structurii datelor din baza de date, astfel încât 
aceasta să satisfacă cerințele tuturor utilizatorilor in condiţii de redundanfá minimă si 
controlată a acesteia (nivel conceptual). Această structură poartă denumirea, în concepția 
CODASYL, de SCHEMA BAZEI DE DATE, iar structura logică este numită SUBSCHEMA 
BAZEI DE DATE. 

O înregistrare virtuală, în general se poate materializa în una sau mai multe 
înregistrări fizice şi poate participa la construirea uneia sau mai multor înregistrări logice. 

În general, structura logică a bazei de date apare la nivelul programului de aplicaţie, 
structura virtuală la nivelul administratorului bazei de date iar structura fizică la nivelul 
inginerului de sistem. 

Legătura dintre nivelul virtual (conceptual) şi cel fizic se realizează de către SGBD. 
Aceasta permite mai multe moduri de realizare fizică a unei înregistrări virtuale iar 
administratorul bazei de date stabileşte tipul de legături preferabil dintre acestea. 

.  ,n figura 1.13. se prezintă cele trei niveluri de organizare a datelor în baza de date si 
raportul dintre ele. 


ak 


Nivelul virtual (conceptual) permite separarea modului de i 
DP na ce Pi i de organizare a datelor de 


Nivel 
CONCEPTUAL 


Nivel 
FIZIC 


Fig. 1.13. Niveluri de organizare a datelor la baze de date centralizate şi/sau locale 


Extem <> Fizic 


Prin această separare a structurii logice de structură vi i i 

următoarele două mari avantaje: [- rires ig ET 

- în procesul de creare şi exploatare a bazei de date activitatea de elaborare a 
programelor poate fi modularizata. Fiecare programator poate să-și scrie 
programele salc fără să fie nevoit să cunoască structura întregii baze de date, ceea 
ce duce la reducerea timpului de realizare a sistemului informatic, având drept 
nucleu O bază de date. In același timp sporeşte confidenialitatea datelor din 
bază, ținând seama de faptul că fiecărui utilizator îi sunt puse la dispoziţie 
numai datele pe care le are specificate la nivelul structurii logice a aplicaţiei. 

- La nivel Virtual (toate cerinţele utilizatorilor) apare posibilitatea găsirii acelei 
structuri globale a bazei de date care să permită satisfacerea tuturor acestor cerințe 
în condiţiile: 

* reducerii volumului memoriei magnetice necesare pentru stocarea 
(memorarea) datelor, prin asigurarea unei redundanje minime si controlate 
a datelor din bază; 

© reducerii timpului de răspuns pentru informaţiile solicitate; 

* reducerii efortului de pregătire, încărcare si actualizare a bazei de date. 


Cele trei tipuri de structuri, corespunzătoare celor trei niveluri de organizare a 

datelor (logic, virtual si fizic) sunt mai sugestive si mai bine redate in figura 1.14, unde: 
- se sugerează aplicaţiile utilizatorilor cu structurile logice implicate (fiecare 
o ES anumiţi indicatori, exemplu Aplicația 1 implică indicatorii A, 


a 


— 2 


k ică nu reprezintă nimic altceva decât modul în care un utilizator 
Garecare percepe/vede structura bazei de date prin prisma intereselor sale de 
aplicaţie; e 
- că dacă datele ar fi stocate pe suportul de memorie externă în 
pou din cu structura. logică a bazei de date, atunci anumiți indicatori/date ar fi 
sies domi muli on. (esses à inte A, B şi D). O astfel de situaţie ar 
a datelor în 

T. me coronis redundanfa datelor, admini: istratorul bazei de date recurge la 
analiza tuturor cerințelor aplicaţiilor utilizatorilor şi apoi va defini o structură 
unică, capabilă să satisfacă cerințele tuturor utilizatorilor în condiţiile de 
redundanjá minimă şi controlată a datelor. Deci, se observă la nivelul structurii 
virtuale că fiecare indicator se regăseşte o singură dată. Această structură 
reprezintă punctul de vedere al administratorului de sistem; > 

— datele vor fi stocate în baza de date conform structurii fizice, care nu reprezintă 

altceva decât punctul de vedere al inginerului de sistem. 


Aplicația 1 
A, B,C,D,H,K 


A, B,C,D,E,F,G,H,1,J,K,L 


PETT IEEE —— 
BAZA DE DATE ncs 


Fig. 1.14. Exemplu de tipuri de structuri 


> 
Punctul de vedere 
al utilizatorului 


> 
Punctul de vedere al 
administratorului de 

bază de date 


> 
Punctul de vedere al 
inginerului de sistem 
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Capitol 2 


Sisteme de gestiune a bazelor de 
date (SGBD -DBMS) 


2.1. Definirea SGBD 


SGBD reprezintă un pachet complex de componente software, fiecare având o 
anumită funcţiune sau obiectiv. 

Cu ajutorul componentelor software ale SGBD se realizează o multitudine de 
activităţi, cum ar fi: definirea structurii bazei de date, încărcarea, exploatarea, întreţinerea, 
protecţia bazei de date etc. În acest context se apreciază că Sistemul de Gestiune reprezintă 
software-ul propriu-zis a bazei de date. Baza de date lipsită de un Sistem de Gestiune nu se 
justifică şi nu poate exista. 

Performanţele. unui sistem depind de eficiența structurilor utilizate pentru 
reprezentarea. datelor în baza de date și de eficienţa cu care sistemul operează cu aceste 
structuri. 

Scopul SGBD este acela de a simplifica şi uşura accesul la date. Acest lucru este 
realizat în general prin asigurarea transparenţei (faţă de utilizator) a modului de 
reprezentare fizică (low level) faţă de modul în care utilizatorul interacționează cu 
datele (viziuni de nivel înalt - high level). 

acest context un SGBD poate fi văzut ca o interfaţă între cel mai scăzut nivel de 
stocare utilizat de baza de date - nivelul fizic - şi programele de aplicaţie sau cererile 
adresate sistemului. 

Accesul utilizatorului final la datele stocate în bază de date, poate fi văzut, la modul 
general ilustrat în figura 2.1. 

In mod obligatoriu SGBD trebuie să cunoască ce fişiere stocate există iar, pentru 
fiecare dintre ele: 

- structura de stocare a înregistrării; 

- câmpurile care compun/descriu înregistrarea; 

-~ câmpurile care pot fi utilizate ca argumente/parametri pentru instrucţiunile de căutare 
în acces direct (dacă astfel de câmpuri există). 

În figura 2.2. este prezentată o detaliere a structurii sistemului de gestiune a bazei de 
date unde utilizatorii pot fi: 

7 Programatori de aplicaţie - apeluri la limbajul de manipulare a datelor (LMD) din 
programe gazda (OCI PRO*C, PRO*Cobol, ... ). 

-~ Utilizatori cauzali - interacționează cu sistemul fără a scrie programe prin 
intermediul unui limbaj de cereri. 

~ Utilizatori obişnuiţi - utilizează programe de aplicaţie. 
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- Utilizatori specializați - utilizează produse CASE, sisteme expert, baze de cunoştinţe. 
- Administratorul BD (ABD) având o serie de sarcini, cum ar fi: 

* definirea schemei (cu ajutorul limbajului de definire a datelor LDD); 

o definirea structurii de stocare şi a metodelor de acces; 

e modificarea schemei fizice si a celei organizatorice; 

e acordarea drepturilor de acces; 

e specificarea restricţiilor de integritate. 


Interfata cu 


realizari de _ 
inregistrari 


Ut atorii 
logice 

Interfata cu 
eanep-p----B------ inregistrarile 
stocate Secste 


Interfata cu 
— Inregistrarile 
Fizice 


realizari de 
inregistrari mipis 


- fizice 
pagini/blocuri) 


Za de Date 
Fig. 2.1. Interfața cu datele stocate 


În figura 2.3 este prezentată o detaliere a interacțiunii componentelor sistemului de date 
la existenja unei cereri utilizator, 
Elementele din figura 2.3 sunt descrise sumar în cele ce urmează: 

-  Analizor Cereri (Compilator, Interpretor - Query Parser) - translatează instrucțiunile 
exprimate în limbajul de cereri in instrucțiuni cod magina (sau un alt limbaj de nivel 
scăzut); 

Selectorul Strategiei de Execuţie - are rolul de a găsi cea mai bună cale de execuţie a 

cererii prin consultarea unor date statistice şi/sau informaţii de sistem. 

-  Gestionarul Autorizărilor şi Integritáfii - testează satisfacerea restricţiilor de integritate şi 
a drepturilor de acces a utilizatorului; 

- Gestionarul Reluării - asigură consistenţa bazei de date în caz de cădere (pană disc. 
întrerupere curent, erori software etc); 

- ` Controlerul Concurenţei - asigură medierea cerinţelor concurenței; 

- Gestionarul Buffer-elor memoriei - este responsabil cu transferul informaţiilor între disc 
şi memoria internă; 

*  Gestionarul de Fişiere - responsabil cu gestiunea spaţiului de stocare, alocarea acestuia si 
structurile de date utilizate pentru a stoca datele în disc. SGBD-ul utilizează diverse 
structuri de date ca părți ale structurii fizice de stocare cum ar fi: 

e Fişiere de Date - destinate stocării bazei de date însăși; 
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o Fişiere de Date Sistem - utilizate pentru a stoca date despre structura bazei de 
date (Dicţionarul Datelor), informaţii privind autorizările şi utilizatorii, restricţii 
de integritate etc. 

. Indecsi - construiți pentru realizarea unui acces rapid la date; 

© Date Statistice - informaţii statistice despre datele conținute în BD. 


Fig. 2.2 Structura sistemului de gestiune a bazei de date 


Gestionarul Bazei de Date (Database Manager) realizează cel puţin următoarele sarcini: 
* interacţiunea cu gestionarul de fişiere al sistemului de operare (SO) gazdă. 
Translateazà diversele comenzi ale LMD în comenzi de acces la nivel scăzut la 
fişiere. De fapt, SGBD este responsabil cu modul curent de stocare, regăsire si 
actualizare a datelor în baza de date; 

* forțează integritatea (fizică, logică si eventual distributivă (integrity enforcement). 
Memorarea datelor în BD este efectuată numai dacă sunt îndeplinite anumite 
restricţii (restricţii de integritate sau restricţii de consistență) definite de către 
SGBD. Aceste restricţii sunt verificate la orice cerere de actualizare, acţiunea 
îndeplinită de SGBD în urma verificării fiind dependentă de violarea sau 

respectarea acestora; 

* forțează securitatea (security enforcement); 

* salvare şi refacere (backup and recovery); 


e jurnalizare /refacere la incident; 
© controlul concurenţei (si partajarea datelor). 


utilizator ionarul Autorizarilor si Integritatii 


analizor cerere 


selector strategie de executie jurnal activitati (log) 


tranzactie ae "T reluari 


gestionar buffere controler concurenta 


tabela blocari 


gestionar fisiere puffer (memoria interna] 


date statistice 
a Memorie Disk 


Fig. 2.3. Structura Sistemului (Detaliu) 


2.2. Obiectivele unui SGBD 


i informaticii îl constituie 

Aşa după cum este cunoscut, obiectul de preocupare a n 
culegerea, verificarea, transmiterea, stocarea i prelucrarea automată a datelor cu ajutori 
mijloacelor electronice de calcul, în scopul satisfacerii diferitelor niveluri de conduc 
informațiile necesare luării de decizii în condiții de eficiență economică sporită. «i 

În condiţiile exploziei informaționale, cerința acută de informare trebuie satisfăci 
ţinând seama de o serie de condiţii care să asigure: 

- minimizarea costului procesului de prelucrare automată a datelor; 
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- creşterea vitezei de răspuns la întrebările solicitate de utilizatori; 

- adaptarea în mod facil a sistemului informatic la evoluția în timp a 
sistemului informaţional din care face parte; 

- posibilitatea răspunsului la anumite întrebări neanticipate de către proicctanfii 
de sistem (prin neanticipare nu sunt incluse printre funcțiunile oferite de sistemul 
informatic); 

ibili de un minim de 

cunoştinţe despre modul de organizare a lui in general şi despre informatică in 

special; 

- ix eas it şi securitatea datelor în ceea ce priveşte modul de păstrare si acces la 
ele etc. 

În acest context, sistemului de gestiune al bazei de date îi revin o serie de obiective, 

cum sunt: 

a) Asigurarea independenței datelor. Se spune că o aplicaţie este dependentă de 
date, dacă este imposibil să schimbi structura de memorare a datelor (modul în 
care sunt memorate datele) sau strategia de acces la date (cum se face accesul la 
date) fără să afecteze aplicaţia. Independenţa datelor este necesară cel puţin din 
următoarele considerente: 

* diferite aplicaţii au nevoie de viziuni diferite ale acelorași date. De 
exemplu, o aplicație utilizează un câmp de dată drept o dată zecimală în timp 
ce o altă aplicaţie utilizează acelaşi câmp de dată ca fiind reprezentată în binar. 
Sistemul va asigura automat conversia între reprezentarea internă a 
acelei date şi reprezentarea necesară fiecărei aplicații; 

~ administratorul bazei de date trebuie să aibă libertatea să schimbe structura de 
memorare sau strategia de acces, ca răspuns la cerințele de schimbare 
(schimbări de standarde, priorităţile aplicaţiilor, unităţile de memorare etc.), 
fără să modifice aplicaţiile existente; 

- existența unei baze de date şi a unor programe de exploatare a ci, care au fost 
folosite o perioadă de timp, reprezintă o investiţie majoră la care nu trebuie să 
se renunțe prea uşor. De aceea se impune cu necesitate ca atunci când apar 
noi cerințe în cadrul sistemului informaţional sau noi software-uri de baze de 
date acesta să poată funcționa cu programele si procedurile existente iar 
datele existente să poată fi convertite. Deci schimbările care se fac la nivel de 
structură de date nu trebuie să modifice programele de aplicaţie. 

În astfel de condiţii, independența datelor poate fi definită drept imunitatea 

programelor de aplicaţii la schimbarea structurii de memorare sau şi strategiei de acces. 

Independenţa datelor trebuie privită din două puncte de vedere generale: 

- independența fizică; 

- independența logică a datelor; 

- şi unul specific pentru baze de date distribuite: 

- independenţa 


distributiva. 

Independența fizică a datelor face ca memorarea datelor şi tehnicile fizice de 
memorare să poată fi schimbate fără a provoca rescrierea programelor de aplicaţie. 

În ceea ce priveşte independenja logică a datelor, aceasta se referă la posibilitatea 
adăugării de noi articole de date sau extinderea structurii conceptuale (globale), fără 
necesitatea rescrierii programelor existente. 

Independența distributivá a datelor face ca schimbarea nodurilor in care se stochează 
baza de date să nu provoace rescrierea programelor de aplicaţie. 
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Prin asigurarea independenței datelor faţă de programele de aplicaţii se asigură 
adaptarea în mod facil a sistemului informatic la evoluţia sistemului informațional în care 
este integrat. 

b) Asigurarea unei redundanțe minime şi controlate a datelor din baza de date. 


Aga după cum s-a mai precizat anterior, prin redundanga datelor în baza de date vom | 


înţelege regásirea sau prezența a aceloraşi date în două sau mai multe colecţii de date. 

Spre deosebire de sistemele clasice de prelucrare automată a datelor, stocarea 
datelor în cazul bazelor de date se face în aga fel încât fiecare dată să apară o singură dată 
(redundanţă minimă). Totuși, nu sunt excluse nici cazurile în care din dorința de a realiza 
performanțe sporite, referitoare la timpul de acces la date si răspuns la solicitările 
utilizatorilor, să se accepte o anumită redundanță a datelor, însă în acest caz sc va institui 
control automat asupra ei în vederea asigurării coerenței datelor din bază. In acest caz se 
spune că avem de a face cu o redundanţă minimă si controlată a datelor. 

€) Asigurarea unor facilităţi sporite de utilizare a datelor. Sub aspectul facilităţilor 
de utilizare se urmăreşte: 

-~ datele să poată fi folosite de mai mulţi utilizatori în diferite scopuri 
(aplicaţii 

- utilizatorii să aibă acces la date într-un mod cât mai simplu, fără ca aceştia să 
fie nevoiţi să cunoască structura întregii baze de date, acest lucru rămânând 
în atenţia administratorului bazei de date; 

- existența unor limbaje performante de regăsire a datelor, care permit 
exprimarea sub forma unei conversații, a unor criterii de selecţie a datelor 
şi indicarea unor reguli cât mai generale pentru editarea informaţiilor 
solicitate; = 

- spre deosebire de sistemul clasic de prelucrare „gen fişier”, unde există un 
singur criteriu de adresare, cel care a stat la baza organizării fişierului, în cazul 
bazelor de. date, sistemul de gestiune trebuie să ofere posibilitatea unui acces 
multicriterial, fără sortări suplimentare, în timp ce modificarea criteriului la 
fişierele clasice implică reorganizarea lor; 

- utilizarea unui limbaj cât mai apropiat de limbajul natural, cu posibilitatea 
exploatării bazei de date în regim conversaţional. Realizarea unui astfel de 
obiectiv oferă posibilitatea exploatării în mod facil a bazei de date şi de 
către utilizatori neinformaticieni. 

Sporirea gradului de securitate a datelor împotriva accesului neautorizat la ele. 

în condițiile bazelor de date, administratorul bazei de date poate prevedea ca 

accesul la baza de date să se facă numai prin canale corespunzătoare, iar pe de altă 
parte, poate defini verificări de autorizare, care să fie realizate oricând se încearcă 
un acces la anumite date. 

€) Asigurarea integrității datelor împotriva unor ştergeri intenționate sau 
neintenţionate a datelor, prin intermediul unor proceduri de validare, a unor 
protocoale de control concurent şi a unor proceduri de refacere a bazei de date după 
incidente. 

f) Asigurarea partajabilităţii datelor. Partajabilitatea datelor trebuie înţeleasă nu 
numai sub aspectul asigurării accesului mai multor utilizatori la aceleași date ci 
şi aspectul că pot fi dezvoltate aplicaţii fără să se modifice structura bazei de date. 
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2.3. Funcţiile unui sistem de gestiune a bazei de date 


Sistemele de gestiune a bazelor de date dispun de o serie de componente ce permit 
efectuarea numeroaselor operaţii implicate de realizarea obiectivelor enumerate la 
paragraful anterior. In funcţie de natura lor şi scopul urmărit, operaţiile pot fi grupate pe 
activitàfi. 

Activităţile acceptă si ele o anumită grupare pe funcfii.Una sau mai multe activităţi, 
relativ omogene, vor realiza o anumită funcție. 

Ținând seama de multitudinea sarcinilor ce revin unui SGBD şi grupând aceste 
sarcini pe activităţi şi apoi pe funcții, în final pot fi deduse funcţiile sistemului de 

estiune. 

a ana de conpleritior Hein do gestiune, de facilităţile propuse a fi 
oferite de acesta, de limbajele utilizate şi tipul bazei de date ce urmează a fi gestionată 
de SGBD, gruparea activităţilor pe anumite funcţii are un caracter relativ. Astfel de exemplu, 
sistemele de gestiune pentru baze de date distribuite vor avea de rezolvat probleme privind 
accesul concurengal într-o forma complexă, localizarea nodurilor cooperante pentru 
satisfacerea unei cerințe informaţionale globale ce solicită date din mai multe noduri ale 
rejelei (din mai multe baze de date locale), dialoguri de comunicare si confirmare de mesaje 
etc. Totodată, funciile sistemelor de gestiune vor comporta amprenta limbajelor folosite 
(SGBD-uri cu limbaje proprii-autonome şi SGBD-uri cu limbaje gazdă de nivel înalt - 
COBOL, FORTRAN, PL/I, C, C++, ADA etc.). 

În situajia sistemelor de gestiune ce utilizează limbaje gazda, de nivel nlt, 
identificarea şi delimitarea funcțiilor nu este atât de evidentă. 


UTILIZATORI 


Fig. 2.4. Funcţiile unui SGBD 


În ciuda acestor particularităţi, totuşi, se pot deduce câteva funcţii cu caracter de 
generalizare pentru toate sistemele de gestiune a bazelor de date. în cele ce urmează ne 
propunem să facem o prezentare sumară a unor astfel de funcții (figura 2.4). 


Funcţia de definire a datelor permite definirea structurii bazei de date cu ajutorul 
limbajului de definire a datelor (LDD). Definirea datelor poate fi realizată la nivel logic, 
virtual şi fizic. La nivelul acestei funcţii se descriu multitudinea atributelor (câmpurilor) din 
cadrul structurii bazei de date, legăturile dintre entităţile bazei de date sau dintre atributele 
aceleiaşi entităţi, se definesc eventualele criterii de validare a datelor, metodelor de acces la 
date, aspectele referitoare la asigurarea integrităţii şi confidenţialităţii datelor etc. 

Rezultatul compilării descrierii exprimate in LDD se va concretiza în schema bazei 
de date memorată, în cod intern, într-un „„fişier” special denumit dicţionarul dalelor (DD - 
data dictionary), Structura de stocare şi metodele de acces utilizate de către SGBD sunt 
specificate cu ajutorul unor instrucţiuni specializate ale LDD care fac parte din limbajul de 
definire a structurii fizice. Rezultatul compilării acestor instrucțiuni este concretizat în 
elemente de specificare a detaliilor de implementare a schemei BD. Aceste detalii sunt 
transparente pentru utilizator. 


Funcţia de manipulare a datelor este cea mai complexă funcţie si realizează 

următoarele activităţi: 

- crearea (încărcarea) bazei de date; 

- adăugarea de noi înregistrări (tupluri); 

- suprimarea unor înregistrări; 

- modificarea valorilor corespunzătoare unor câmpuri; 

- căutarea, sortarea si editarea parfiala sau totală a unei înregistrări virtuale etc. 

Datorită complexităţii acestei funcţii, pentru anumite SGBD-uri ea se poate subdivide 
în următoarele subfuncţii de : 

- creare iniţială a bazei de date; 

- actualizare şi interogare/extragere a datelor. 

Funcţia de manipulare a datelor se realizează prin intermediul limbajului de 
manipulare a datelor. 


Funcţia de utilizare asigură mulţimea interfejelor necesare pentru comunicarea 
tuturor utilizatorilor cu baza de date. 

În cadrul realizării acestei funcţii apar mai multe categorii de utilizatori: 

- utilizatori liberi" sau  conversafionali. Aceştia reprezintă categoria 
beneficiarilor de informaţii (utilizatori finali) si utilizează limbajele de interogare a bazei de 
date într-o formă simplistă. Ei apar ca utilizatori neinformaticieni; 

~ utilizatori programatori care fac uz de limbajele de manipulare, realizând proceduri 
complexe de exploatare a bazei de date; 

- administratorul bazei de date apare ca un utilizator special şi are rolul hotărâtor 
în ceea ce priveşte funcţionarea optimală a întregului ansamblu. 


Funcţia de administrare a bazei de date apare ca o funcție complexă şi este de 
competenţa administratorului bazei de date. Aceasta funcţie va fi tratată în detaliu la 
capitolul privind administrarea bazei de date. 


2.4. Arhitectura sistemelor de gestiune a bazelor de 
date 


Ţinând seama de faptul că există diferite tipuri de sisteme de gestiune, ca ele se 
diferenţiază prin limbajele utilizate, prin anumite componente ce imprimă diferite facilităţi 
de exploatare a bazei de date, prin faptul că unele oferă posibilitatea lucrului în regim de 
teleprelucrare, altele numai în regim local iar altele atât în regim local cât si în regim de 
teleprelucrare, nu poate fi dată o arhitectură unică valabilă pentru toate sistemele, Deci, apar 
particularităţi de la un sistem la altul. 

Totuşi există preocupări de standardizare a arhitecturii sistemelor de gestiune, care 
caută să definească cadrul general al acestora. 

În acest context vom căuta să două arhitecturi de referinţă a unui SGBD 
propuse de grupul de lucru CODASYL si ANSUX3/SPARC. 


24.1. Arhitectura unui SGBD în concepţia CODASYL 


În figura 2.5. este redată arhitectura unui SGBD în concepția CODASYL. Din figura 
25. se pot deduce cele trei nivele de organizare a datelor şi structurile corespunzătoare, 
precum şi operaţiile declanşate de derularea unui program de aplicație sub controlul unui 
SGBD. 
Succesiunea logică a operaţiilor declanşate de un program de aplicaţie apare astfel: 
- Programul de aplicaţie A lansează o cerere de citire a datelor din baza de date. 
Cererea este lansată către SGBD. 
- Sistemul de gestiune interpretează cererea, consultând SUBSCHEMA 
referitoare la programul de aplicaţie A. 
- Sistemul de gestiune apelează SCHEMA bazei de date și determină la nivel logic 
datele solicitate din cadrul unei înregistrări virtuale, 
~ Sistemul de gestiune examinează descrierea fizică a bazei în raport cu cererea 
logică şi determină înregistrarea fizică care interesează. 
- Sistemul de gestiune lansează o comandă către sistemul de operare sub 
controlul căruia lucrează pentru căutarea înregistrării fizice de citit. 
~ Sistemul de operare cut înregistrarea fizică. 
- înregistrarea fizică găsită este transferată în memoria tampon a sistemului de 
gestiune, 
- SGBD procedează la o comparare între SCHEMA bazei de date şi SUBSCHEMA 
corespunzătoare aplicaţiei A si identifica datele solicitate de programul A. 
- SGBD transferă datele din memoria tampon în zona de lucru rezervată 
programului de aplicaţie A. 
- Programul de aplicaţie A preia controlul asupra tratării datelor solicitate iar pe 
parcursul executării programului se realizează un schimb de informaţii cu SGBD 
referitoare la „starea programului” sau eventualele erori constatate, 


Operaţiile de scriere în baza fizică sunt tratate de către un procesor, similar, toate 
modificările sau adăugirile sunt în general precedate de o operație de citire. 
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2.4.2. Arhitectura propusă de grupul ANSI/SPARC 


Grupul de cercetători de la ANSI/SPARC prezintă o altă arhitectură pentru o bază de 
date privită ca sistem. Această arhitectură pune accentul pe interfețele dintre componentele 
sistemului şi pe interfețele dintre componente si diferite categorii de utilizatori (roluri 
umane). Partea importantă a arhitecturii ANSI este prezentată în figura 2.6. 1 

Se remarcă trei roluri umane în definirea schemelor: 4 

- Persoana sau grupul de persoane care defineşte schema conceptuală a bazei de 

date, Schema conceptuală reprezintă „cel mai bun model” pentru întreprindere. 
Ea furnizează o viziune pe termen lung şi reprezintă baza pentru declaraţiile de 
securitate si integritate, precum şi pentru standardele impuse de întreprindere 
diferiților utilizatori. 

- Persoană sau un grup de persoane care descriu o schemă externă pentru o. 

aplicaţie particulară. Într-o întreprindere există mai multe roluri de acest fel. il 

- Administratorul bazei de date are responsabilități privind definirea schemei 

interne a bazei de date. Tot el asigură şi întreținerea acesteia. 


MANIPULARE 
Fig. 2.5. Arhitectura unui SGBD conform propunerii CODASYL 


Schemele astfel definite sunt verificate de procesoarele corespunzătoare şi, dacă sunt 
valide, sunt memorate în dicţionarul datelor. 

Declararea schemei conceptuale a bazei de date se realizează prin intermediul 
interfeţei 7. 

După compilare definirea este memorată în cadrul dicționarului datelor prin 
interfața 2. Administratorul bazei de date şi administratorii aplicaţiilor iau cunoştinţă de 
schema conceptuală prin intermediul interfeţei 3. 
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Prin intermediul interfeţei 4 se specifică declaraţiile schemelor externe, a căror formă 
compilată este memorată în dicţionarul datelor prin interfața 5. 

Declaraţiile schemei interne a bazei de date se specifică prin intermediul interfeţei 6. 
schema internă compilată este memorată în dicţionarul datelor prin intermediul interfeţei 7. 

le din dicţionarul datelor sunt puse la dispoziția modulelor de transformare prin 

interfețele 8, 9 si 10. 

Interfejele 77 si 12 sunt utilizate în timpul execuţiei, pentru transmiterea datelor şi 
comenzilor între nivelele bazei de date (memorie, intern, cra şi extern). 

Programatorii de aplicaţii si utilizatorii finali comunică cu SGBD-ul prin intermediul 
limbajului de manipulare sau a limbajului de interogare (interfața 13). 

. Prin intermediul interfeței 74 schema externă este pusă la dispoziția programului de 
aplicaţie pentru ca acesta sa poată fi compilat/translatat/interpretat. La execuţie toate cererile 
de acces la date sunt transmise prin interfaţa 74 la sistemul de gestiune a bazei de date. 

, Dacă sunt necesare schimbări ale structurii de memorare sau a strategiei de acces (din 
motive de performanţă, schimbarea suporturilor de memorie etc.) la date, programatorii de 
sistem prin intermediul interfeței 75 specifică programele respective, ale căror efecte se 
vansmit SGBD-lui prin intermediul interfeţei 16, fără a afecta nivelurile conceptual şi 
extem. 


[7] 


o» 


T Fig. 2.6. Arhitectura ANSI a unui SGBD 


Arhitectura ANSI pune, în acest fel, în evidenţă următoarele aspecte: 
„ - definirea schemei conceptuale; 

- definirea schemelor externe; 

- definirea schemei interne; 

- funcţiile de transformare şi independenţa datelor. 


4n 


Făcând o analiză sumară a celor două tipuri de arhitectură se pot desprinde uncle 


aspecte esențiale comune. Astfel, schema bazei de date din cadrul propunerii CODASYL 
poate fi identificată cu schema conceptuală din arhitectura ANSI/X3/SPARC. Şi într-un 
caz şi în altul apar schemele la nivel intern si extern, doar denumirile diferă într-o oarecare 
măsură. Totodată, se observă că factorul uman este surprins şi într-un caz şi altul, cu o 
evidenfiere mai pronunţată în cazul propunerii ANSI. 


2.4.3. Arhitectura client/server 


În paragrafele precedente au fost prezentate două tipuri de arhitecturi de SGDB, si 
anume CODASYL si ANSI. Acum vom căuta să prezentăm arhitectura unui sistem de baze de 
date dintr-un alt punct de vedere, şi anume, se va avea în atenţie partajarea activităţilor 
sistemului de baze de date între două sau mai multe calculatoare, conectate în rețea, i care 
cooperează între ele. O astfel de arhitectură poate fi privită ca având o structură foarte simplă 
formată din două părți, partea client din programele sistemului ce mai poartă denumirea de 
front-end şi partea server ce mai poartă denumirea de back-end. Acum să vedem ce 
semnificaţii au cele două concepte client şi server. Clientul reprezintă un solicitant sau un 
beneficiar de servicii oferite de server, cu alte cuvinte atât clientul cât şi serverul reprezintă 
anumite programe ce execută anumite sarcini/activităţi. În contextul bazelor de date, Serverul 
este tocmai SGDB în sine, instalat pe un anume calculator. Acesta are rolul de a rezolva şi 
satisface toate cerințele privind funcţiile de bază, şi anume definirea datelor, manipularea 
datelor, protecția bazei de date sub aspectele de securitate şi integritate etc. Într-o astfel de 
situaţie, conceptul de server reprezintă o altă denumire a SGDB. 

Clienţii sunt diversele aplicaţii, care rulează deasupra SGDB-ului, atât aplicaţiile 
(programele) scrise de utilizatori, cát şi cele încorporate în cadrul SGDB sau chiar altele 
furnizate de altcineva. Remarcăm faptul că, din punctul de vedere al serverului nu există nici 
o diferență între aplicaţiile scrise de utilizator şi cele încorporate, toate folosesc aceeaşi 
interfață cu serverul, şi anume interfaţă la nivel extern. 

Referitor la cele două componente, client şi server, componenta client se execută 
independent pe fiecare staţie de lucru client (client workstation). Ea este activată de utilizator 
şi rămâne activă doar pe durata unei sesiuni de lucru, perioadă în care răspunde cerinţelor 
unui singur utilizator. Componenţa server se execută pe calculatorul server, funcţionează non 
stop şi răspunde cerinţelor tuturor posturilor de lucru active. 

În figura 2.7. este redată arhitectura client/server, într-o formă sugestivă. 

Referitor la „aplicaţii”, acestea pot fi grupate astfel: 

- Aplicații scrise de utilizator, care sunt altceva decât programe de aplicaţii obişnuite 

scrise într-un limbaj de programare, cum ar fi C++, SQL, COBOL, PASCAL etc.; 

- Aplicaţii furnizate de producător şi regăsite cu denumirea de instrumente (tools) 

având ca scop de a uşura activitatea utilizatorilor de proiectare, creare, încărcare şi 
exploatare a bazei de date. Spre exemplificare am putea aminti: generatoare de 
rapoarte, generatoare de aplicaţii, utilitare pentru încărcarea masivă a bazei de 
date, utilitare pentru reorganizarea bazei de date, componente statistice, 
instrumente de tip CASE, foi de calcul tabelar, utilitare pentru grafică interactivă, 
utilitare de import/export de date din baza de date etc. 

În ceea ce priveşte distribuirea activităţilor sau sarcinilor pe cele două componente, 
front-end respectiv back-end, s-au conturat anumite orientări, astfel: pe front-end ar fi 
asigurarea interfeței cu utilizatori, cereri de date, sau prelucrări, procesarea comenzilor de 
interogare sau definire a bazei de date, formatarea răspunsurilor primite de la server si 
prezentarea lor utilizatorilor etc. Pe back-end sunt rezolvate o serie de sarcini privind 
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preluarea cererilor referitoare la datele solicitate de utilizatori, evidenţierea versiunilor 
structurii bazei de date, servicii referitoare la asigurarea confidenţialităţii si integrităţii bazei 


de date etc. 


Utilizatori finali 


Clienţi 


Server 


Fig. 2.7. Arhitectura client/server 


. n încheierea acestui paragraf, precizăm faptul că există mai multe variante ale 
arhitecturii client/server în funcţie de numărul de niveluri adoptat. În paragraful următor va fi 
prezentată arhitectura client/server pentru SGDB-Oracle. 


2.4.4. Arhitectura SGBD Oracle 


, . Oracle este un SGBDR complet relational, extins cu facilităţi din tehnologia orientată 
obiect, tehnologia OLAP şi tehnologia Internet (8i, 9, 10g) care se situează pe primele locuri 
pe piaţa SGBD-urilor. Este operabil pe toată gama de calculatoare sub diferite sisteme de 
operare (Unix, Windows, Linux) si este destinat întreprinderilor medii şi mari, existând si 
versiuni pentru întreprinderile mici (Express Oracle). 

Firma Oracle Corp. a fost înfiinţată in 1977 în California -SUA şi este la ora actuală 
cel mai mare furnizor de software pentru gestiunea informaţiilor. Prima versiune de Oracle 
comercială a fost realizată în 1979. Firma a implementat de la început limbajul SQL, pe care 
l-a dezvoltat ulterior faţă de standard. 

> cu versiunea 5.0, SGBD Oracle funcționează în arhitectură client/server, are 
limbaj procedural Ends PL/SQL, are precompilatoare ca interfaţă cu limbajele de 
programare universale. Într-o configuraţie client/server pe două niveluri componentele client, 
respectiv server sunt plasate pe calculatoare diferite într-o reţea: serverul asigură memorarea 
3i manipularea datelor, precum şi administrarea bazei de date, iar clientul asigură interfaţa cu 


utilizatorul si lansează aplicaţii care accesează datele din baza de date. 


51 


n— Zi 


Capitolul 2 


În 1995 Oracle achiziţionează Express, una din principalele tehnologii OLAP folosite, 
iar în iunie 1997 se lansează Oracle versiunea 8 care a marcat o nouă generaţie cu următoarele 
caracteristici 

- inițiază trecerea de la arhitectura client/server la arhitectura Network Computing si 
Internet Computing. Avantajele acestei arhitecturi sunt: deschidere, standarde, | 
flexibilitate, interoperabilitate, extensibilitate, preţ redus; | 

- este un sistem “deschis” (open system) care respectă standardele în vigoare | 
referitoare la limbajele de definire şi manipulare a datelor. Suportă comunicarea cu 
limbajele procedurale de nivel înalt şi pune la dispoziţie un limbaj procedural 
propriu PL/SQL; 

- permite dezvoltarea de sisteme de baze de date de orice dimensiune, centralizate 

sau distribuite; 

suportă zeci de mii de utilizatori; 

are un optimizator de cereri performant ; 
oferă facilităţi de salvare/restaurare automate; 
permite partiționarea tabelelor şi a indecșilor; 
oferă facilități din tehnologia orientată obiect, tehnologia OLAP şi depozite de 
date; 

„oferă o securitate sporită . 

În 1997 firma lansează versiunea 8i cu următoarele caracteristici: 

- prima bază de date pentru Internet, cu suport nativ Java ; 

- este operabilă pe toată gama de calculatoare, sub orice sistem de operare; 

- oferă o gamă largă de instrumente pentru dezvoltare aplicaţiilor cu baze de dater 
instrumente CASE (Oracle Designer 6i), generatoare (Forms &Reports 6i), Ja: 4 
Developer, Web DB, ete; ^ 

- limbajul PL/SQL si limbajul Java sunt integrate; 

- oferă facilități imbunătăţite pentru depozite de date si inteligența afacerilor ; 

în 1999 firma lansează prima bază de date cu suport XML. În 2002 se lansează 
Oracle9i Release 2 OLAP care integrează toate facilităţile OLAP în baza de date relaţională 
Oracle, iar în 2003 se lansează Oracle 10g (ultima versiune 10.2) care integrează facilităţile 
oferite de bazele de date relationale cu facilităţile oferite de tehnologia OLAP, data mining si 
depozite de date: 

- opțiunea OLAP include un motor de calcul multidimensional ce permite analize 

foarte complexe pe datele stocate în spaţiul analitic si are la bază tehnologia 
Express. Datele stocate în spaţiile analitice sunt manipulate cu ajutorul limbajului 
de manipulare OLAP (OLAP DML). Acest limbaj este echivalentul 
“multidimensional” al limbajului PL/SQL şi extinde facilităţile analitice ale 
limbajului SQL. Include funcții pentru analiza seriilor de timp, funcții financiare, 
funcții statistice, o mare varietate de metode de agregare (după nivelul din ierarhie, | 
după anumiți membrii, etc). Datele pot fi stocate în tabele (tabele de fapte şi tabele 
de dimensiuni) sub formă de schemă stea sau fulg de zăpadă sau în variabilele din 
spaţiul analitic, iar utilizatorii pot accesa datele printr-o interfață OLAP (de 
exemplu instrumentul Oracle BI Beans) sau cu ajutorul limbajului SQL (de | 
exemplu instrumentul Oracle Discoverer); 

- opțiunea Data Mining include un motor data mining ce poate fi accesat printr-o 
interfaţă Java. Oferă algoritmi pentru găsirea de tipare în date şi pentru a realiza 
predicții plecând de la aceste tipare ; i 

- opțiunea Partitioning permite administratorilor de baze de date să partijioneze | 
datele pentru a îmbunătăţi performanța. 


Sisteme de gestiune a bazelor de date 


Începând cu versiunea 10g, pentru îmbunătățirea managementului resurselor s-a 
s utilizarea unei noi tehnici şi anume tehnica grid computing care va influența modul de 
repartizare şi de folosire simultană a resurselor. Această tehnică permite adăugarea, sau 
scoaterea discurilor de stocare, cu păstrarea on-line a aplicaţiilor. Performanjele serverelor 
sunt puse la dispoziția mai multor aplicaţii si baze de date, într-o structură eficientă de tip 
cluster. Resursele serverelor se alocă în funcție de necesităţile firmei şi folosind tehnica Joad 
balancing se urmăreşte încărcarea diferitelor echipamente, permiţând ca mașina cu cele mai 
puţine poen să primească o nouă sarcină. 
icle a introdus şi un instrument special pentru tul grid-ului " 
Oracle Grid Control pe care administratorii de sistem il ii pa 
modificarea întregii infrastructuri IT ce include resurse eterogene, distribuite geografic. 
Resursele nu mai sunt administrate individual, așa cum se realiza în mod tradițional, ci grupat 
prin utilizarea unui browser Web. Astfel se poate realiza managementul resurselor de tip: 
servere de aplicaţii, servere de baze de date, echipamente de stocare, echipamente de rețea. — 
»" Oracle Enterprise User Security este o componentă de management centralizat a 
privilegiilor de acces a utilizatorilor. Practic un utilizator este creat o singură dată, putând 
avea acces la multiple baze de date existente in grid. Oracle Identity Management 
centralizează managementul autentificării si autorizării utilizatorilor în cadrul unei soluţii 
integrate, prin intermediul componentei denumite Oracle Internet Directory. 
, O arhitectură de tip grid computing presupune o multitudine de echipamente hardware 
şi de aplicaţii software care comunică prin intermediul Intranetului sau a Internetului şi 
permite în mod transparent accesul utilizatorilor la serviciile grid-ului fără ca aceștia să 
identifice resursele care procesează operaţiile într-un mod unitar. 


2.44.1. Arhitectura pe componente a SGBD Oracle 


eee ERE Wee e pe dire a SGBD Oracle. Nucleul 
le care dau tipul relafi ntru SGBD : 
- Limbajul SQL ds S 
- Limbajul procedural PL/SQL 
- Limbajul Java 


Nucleul Oracle (SQL, PL/SQL, Java) 


Fig. 2.8. Arhitectura pe componente a SGBDR Oracle 
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SGBD Oracle creează si întreţine în mod automat un dicționar de date format dintr-un 
set de tabele şi tabele virtuale folosite pentru a oferi informaţii despre datele din baza de date, 
Dicţionarul de date este o sursă centrală de informaţii pentru Oracle si pentru toți utilizatorii 
bazei de date. Se actualizează în mod automat atunci când o comanda de definire/manipulare 
se execută. Utilizatorii accesează foarte rar tabelele de bază, deoarece ele sunt normalizate. 

Tabele virtuale ale dicționarului de date conţin o sinteză a informaţiilor din tabelele de 
bază. Pe aceste tabele virtuale sunt create sinonime publice pentru ca utilizatorii să le acceseze 
mai ușor. Tabelele virtuale ale dicționarului sunt clasificate în trei categorii: 

-~ Tabele virtuale a căror denumire este de forma USER XXX. Aceste tabele sunt 
accesibile oricărui utilizator şi în general se referă la obiectele aparținând 
utilizatorului curent. De exemplu, tabela virtuală USER TABLES conţine 
informaţii despre tabelele utilizatorului curent: 

SELECT TABLE_NAME FROM USER_TABLES; 

- Tabele virtuale a căror denumire este de forma ALL XXX. Aceste tabele sunt 
accesibile oricărui utilizator şi oferă informaţii despre obiectele la care utilizatorii 
au acces prin drepturi publice (PUBLIC) sau explicite şi roluri. De exemplu, tabela 
virtuală ALL_USERS conţine informaţii despre utilizatorii bazei de date: 

SELECT USERNAME FROM ALL_USERS; 

- Tabele virtuale a căror denumire este de forma DBA XXX. Aceste tabele oferă 
informaţii despre toate obiectele bazei de date si sunt folosite de administrator sau 
de orice utilizator cu drept de SELECT ANY TABLE. De exemplu, tabela virtuală 
DBA_DATA_FILES conţine informaţii despre structurile fizice ale bazei de date : 

SELECT * FROM DBA_DATA_FILES; 
Tabele virtuale dinamice (dynamic performance views) care se actualizează 
automat şi oferă informaţii legate de performanţa sistemului. Aceste tabele sunt 
accesibile numai administratorului bazei de date. De exemplu, tabela virtuală 
VSSESSION . 

Instrumentele de dezvoltare permit dezvoltarea aplicaţiilor cu baze de date. Oracle 
Developer Suite integrează într-un singur pachet o serie de instrumente de dezvoltare si 
anume: 

- Oracle Warehouse Builder este un instrument pentru modelarea şi generarea 

depozitelor de date, precum şi pentru încărcarea datelor în depozite de date ; 

- Oracle Reports este format din: Reports Developer pentru crearea rapoartelor şi AS 
Report Services pentru distribuirea rapoartelor pe Internet. Utilizatorii pot accesa 
rapoartele utilizând un browser Web (de exemplu Internet Explorer) sau pot alege 
formatul de afişare (HTML, XML, pdf, etc) ; 

- Oracle Discoverer este un instrument pentru raportare si interogare ad-hoc. Este 
proiectat pentru a fi utilizat atât de dezvoltatori (Discoverer Administrator) cât si 
de utilizatorii finali (Discoverer Desktop). Poate accesa atât date relaţionale cát si 
multidimensionale. 

-~ Oracle JDeveloper este un instrument ce permite dezvoltarea de aplicaţii utilizând 
limbajul Java. 

- Oracle Forms Developer (figura 2.9.) permite generarea de videoformate si 
meniuri, utilizând limbajul SQL, PL/SQL si Java. 

- Oracle Designer este un instrument CASE destinat analigtilor de aplicaţii şi oferă 
suport pentru toate etapele de realizare a unui sistem informatic (analiza, 
proiectare, implementare), Pentru analiza statică a sistemului utilizează diagrama 
entitate-asociere, pentru analiza funcțională si dinamică a sistemului utilizează 
taia de geboten (Process Module), dista Jeubiel de Aaoi Fiction 
Hierarchy Diagrammer). Pentru etapa de proiectare foloseşte Database Design 
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Oracle Designer este integrat cu Oracle Forms Developer şi Oracle Reports 
ea EA AE Ean Pe server există un depozit 
central (repository) — un set de tabele şi alte obiecte stocate în mai multe spații 


permite 
tipuri de baze de date: Oracle 7, 8, 8i, 9i, 10g, DEA SQL Server şi a următoarelor 
tipuri de aplicaţii: videoformate şi biblioteci pentru Oracle Forms Builder, aplicaţii 
Visual Basic, aplicaţii Web. 
Oracle BI Beans este un set de componente dés emo co ud dezvoltatori 
să implementeze rapid aplicaţii analitice, accesând motorul OLAP. 


secret pentru a clasifica informaţiile şi pentru a restricționa accesul la aceste 
informaţii. Oracle Label Security stabileşte accesul la tupluri în funcţie de eticheta 
conținută in tuplu, eticheta asociată cu fiecare sesiune a bazei de date și în funcţie 
de privilegiile stabili 


Instrumente pentru configurare şi migrare : 


Oracle Database Configuration Assistant se utilizează pentru a crea, a configura 
sau a şterge o bază de date (figura 2.12.). 

Oracle Administration Assistant for WNT se utilizează pentru a crea administratori 
de baze de date, operatori, utilizatori şi roluri în Windows NT. De asemenea, 
permite gestionarea serviciilor bazei de date, pornirea/oprirea bazei de date, etc; 
Oracle Database Upgrade Assistant se utilizează pentru a se trece de la o 
versiunea la altă versiune a bazei de date. 
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Fig. 2.12. Instrumentul Database Configuration "Astistant 


În tabelul 2.1 şi în figura 2.13. este prezentată platforma Oracle pentru dezvoltarea 
aplicaţiilor cu baze de date 


e — — | 


Tabelul 2.1. Platforma Oracle pentru dezvoltarea aplicaţiilor 


Sisteme informatice Oracle Developer Suite 


afacerilor (BI) 


te Java. JDeveloper, Oracle Application Server 
site-uri Web Oracle ion Server Portal, Oracle Database Server 
Sisteme informatice — | Instrumente BI (Reports Developer, Reports Services, BI Beans, BI 


pentru inteligența Spreadsheet Add-In, Data Miner, Bl Discoverer, XML Publisher) 
Aplicaţii BI preconstruite (Oracle Daily Business Intelligence/DBI, 
Corporate Performance Management, PeopleSoft Enterprise 


Performance Management, Oracle Activity Based Management, etc 


Fig. 2.13.. Platforma Oracle pentru dezvoltarea aplicaţiilor 


Utilizatorii bazei de date Oracle pot executa: 


sale comenzi SQL folosind un instrument (de exemplu SQL Developer (figura 
14); 

o aplicație ce conține comenzi SQL (de exemplu o aplicaţie realizată cu Oracle 
Forms Developer). 


Un utilizator Oracle se poate conecta la serverul Oracle în mai multe moduri: 


se conectează direct la server (pe maşina pe care este instalat serverul Oracle 
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folosind de exemplu instrumentul SQL Developer ); 

- foloseşte o conexiune client/server (de exemplu utilizatorul lansează instrumentul 
Oracle Forms Developer (modulul Forms Builder) instalat pe client care accesează 
baza de date stocată pe server); 

- foloseşte o conexiune pe trei niveluri unde clientul comunică cu un server de 
aplicaţii (Oracle AS) care este conectat prin rețea la serverul de bază de date, 
Clientul poate fi un simplu browser (de exemplu Internet Explorer) care utilizează 
o aplicaţie rezidentă pe serverul de aplicaţii (de exemplu Oracle e-business suite) 
prin care sunt accesate datele stocate pe serverul de bază de date ). 


Oracle AS este un server de aplicaţii bazat pe Java şi constă dintr-un set de servicii 
(servicii pentru comunicaţii, servicii pentru prezentare, servicii pentru managementul datelor 
pentru a reduce încărcarea pe instanța bazei de date, etc) şi utilitare care pot fi utilizate pentru 
a implementa aplicaţii într-un mediu distribuit. 

Oracle AS Portal, care a evoluat din Web DB, este un mediu de dezvoltare a portal- 
urilor, bazat pe standardul J2EE. Conţine portlet-uri ce pot fi îmbunătăţite, ce pot accesa surse 
de date externe prin JDBC sau drivere native Oracle 9i/10g. De asemenea, confine facilitatea 
OmniPorilet prin care se pot accesa date stocate în foi de calcul tabelar şi documente HTML 
şi publicarea acestor date în diferite formate. 

Oracle e-business Suite este un pachet software integrat de mare complexitate ce oferă 
suport integrat pentru activităţile de bază ale unei firme: management financiar (contabilitate 
generală, contabilitatea furnizorilor, contabilitarea clienţilor, gestiunea lichidităților, mijloace 
fixe); aprovizionare; gestiunea stocurilor; desfacere; producţie; managementul proiectelor de 
investiţii; analiză financiară (analiză de indicatori de performanță financiară); managementul 
resurselor umane şi salarizare; managementul relaţiilor cu clienţii (marketing, vânzări, 
service, etc), etc. De exemplu, modulul pentru managementul resurselor umane si salarizare 
(HRMS) include următoarele componente: HR (resurse umane), Payroll (Salarizare), Self 
service HR (angajaţii au acces on-line la aplicaţia HR şi pot modifica on-line informaţiile 
despre ei); Learning Management. (managementul cursurilor); iRecruitment (recrutare on- 
line); Oracle Timer &Labour (pontaje) şi Daily Business Intelligence un set de module de 
raportare şi pagini portal capabile de a prezenta o sinteză zilnică a unei afaceri 


2.4.42. Structura fizică a BD Oracle 


Baza de date Oracle este identificată printr-un nume (parametru DB. Name din fişierul 

de parametri) si este formată din următoarele tipuri de fișiere: 

-~ Fişiere de date (data files). O bază de date Oracle are mai multe fişiere de date 
care conţin toate datele stocate în baza de date (tabele, indecsi, sinonime, triggeri, 
proceduri stocate, funcţii stocate, pachete, etc). Un fişier de date poate fi asociat cu 
o singură bază de date şi se poate extinde în dimensiune în mod automat. Unul sau 
mai multe fişiere de date corespund unui spațiu tabel (tablespace). Fisierele de date 
stochează şi imagini ale datelor înainte de a fi modificate de tranzacţiile curente. 

inte de a face o modificare, procesul server salvează vechea valoare într-un 
segment de rollback. Această imagine este folosită pentru a anula modificările, 
dacă tranzacţia este anulată si pentru restaurarea bazei de date. 

- Fişiere jurnal de tranzacţii. O bază de date are un set de 2 sau mai multe fişiere 
jurnal de tranzacţii în care sunt înregistrate toate modificările făcute asupra datelor 
din baza de date. Aceste fişiere sunt foarte importante în procesul de restaurare a 
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bazei de date. y 
Figierele jurnal de tranzacții arhivate sunt copii ale fişierelor jurnal de tranzacţii 
on-line. Dacă baza de date este configurată la creare cu opțiunea ARCHIVELOG 
atunci fişierele jurnal de tranzacţii on-line sunt arhivate automat. 


L 


Fişierul de control conține informaţii despre structura fizică a bazei de date | 
(numele bazei de date, numele si locaţia fişierelor de date si a fişierelor jurnal de | 
tranzacţii), informaţii pentru salvări/restaurări utilizate de Recovery Manager. Ori 


de câte ori o instanță Oracle este pornită, fişierul ei de control este utilizat pentru a 
identifica baza de date si fişierele de date respectiv fişierele jurnal de tranzacții ce 
trebuie deschise. Oracle recomandă cel puţin 2 fişiere de control identice. 

Un fişier de parametri utilizat pentru a defini caracteristicile unei instanţe Oracle 
Un fişier de parole pentru autentificare utilizatorilor. 


Fig. 2.14. Instrumentul SQL Developer 
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Capitolul 3 
Administrarea bazelor de date 


3.1. Sarcinile administratorului bazei de date (ABD) 


Sarcina de organizare si administrare a unei baze de date revine unei persoane 
sau grup de persoane cu experiența bogată în activitatea de analiză, proiectare și 


Pentru rezolvarea acestei sarcini este necesară o funcţie de administrare a datelor 
care este realizată de regulă, de o persoană sau de un grup de persoane denumit în mod 
generic, administratorul bazei de date (ABD/DBA). Administratorul răspunde de toate 
activităţile şi operaţiile referitoare la baza de date pe care o gestionează, precum și de 
performanțele întregului sistem implementat. Funcția de administrare a datelor a apărut de fapt 
atât din necesitatea proiectării si întreţinerii structurii bazelor de date precum si din necesitatea 
realizării controlului structurii generale a datelor. 

Numărul de persoane variază în funcţie de dimensiunea si complexitatea bazelor de 
date şi a sistemului prin care acestea sunt gestionate. 

Membrii grupului de administrare sunt orientaji fie pe probleme utilizator, fie pe 
probleme tehnice pentru asigurarea unor bune servicii de supervizare funcţională asupra 
performanţei sistemului de baze de date la un cost rezonabil. 

În ultimul timp se vorbeşte de două tipuri de responsabilități de administrare a 
datelor şi anume: 

- administrare a datelor, care se referă la aspectele conceptuale ale proiectării, care nu 
vizează un anumit sistem de gestiune a datelor (schema conceptuală a datelor); 

- administrare a bazei de date, care se referă la deciziile şi activităţile care conduc sau 
au impact direct asupra bazei de date operaţionale vizând activităţi de proiectare 
tehnică şi implementare în care e implicat SGBD-ul. 


Sarcinile ce revin administratorului bazei de date pot fi grupate astfel: 

În etapa de concepție a bazei de date: 
- defineşte obiectivele sistemului informatic al cărui nucleu urmează să fie o 
bază de date; 

- ajută la definirea cerințelor de aplicație la definirea şi descrierea datelor; 

- evaluează cerințele de aplicaţie. ale tuturor utilizatorilor, defineşte 
dicţionarul de date si relațiile logice dintre diferitele categorii de date; 

- defineşte structura conceptuală/virtuală a bazei de date ţinând cont de 
cerinţele tuturor utilizatorilor; 

- împreună cu inginerul de sistem defineşte structura fizică a bazei de date, 
regulile de apartenenţă la spaţiul fizic, relaţiile fizice între înregistrările din 


a 


3.2. 


baza de date, tehnicile de comprimare a datelor în vederea utilizării cât mai 
raționale a memoriei externe; 

- stabileşte procedurile de validare a datelor; 

- elaborează concepția de protecție și securitate a datelor; 
evaluează concepţia de ansamblu a sistemului. 

1n etapa de implementare a bazei de date: 

- elaborează și definitivează documentația de sistem; 

- defineşte strategia si tactica de implementare a sistemului informatic; 

- asigură încărcarea bazei de date plecând de la fișierele deja create sau de la 
culegerea datelor din documentele primare; 

- testează lanţurile de programe şi evaluează performanţele bazei de date. 


În apa de exploatare şi menținere în funcțiune: 
autorizează accesul la baza de date şi asigură protecția şi securitatea 
datelor; 
- asigură utilizarea raţională a spaţiului de memorie rezervat bazei de date; 
- asigură funcţionarea bazei de date la nivelul performanţelor stabilite in 
proiect. 


Functiuni de administrare a bazelor de date 


Administrarea bazelor de date implică mai multe funcţii: 

funcţii de proiectare, definire si implementare a bazei de date; 
funcţii de proiectare a subsistemelor de administrare a bazei de date; 
funcţii de asistentă la realizarea aplicaţiilor care utilizează baza de date; 
funcţii de monitorizare a utilizării bazei de date; 

funcţii de perfecţionare a performantelor exploatării bazei de date; 
funcţii de asistare utilizator; 


Funcția de proiectare, definire şi implementare a bazei de date constă în: 

definirea modelului conceptual al datelor sistemului; 
definirea schemci bazei de date; 

definirea subschemelor la nivelul fizic al aplicaţiei; 

stabilirea liniilor directoare de proiectare logică a sistemului de baze de date prin 
indicarea organizării logice a bazei de date, a numărului de realizări pentru fiecare 
entitate, a perioadelor de păstrare a datelor; 

aa ee oaia A slinami) din baza de deis Int-un limb de descere a 
datelor (LDD) prin definirea atributelor logice si fizice ale datelor, a legăturilor 
dintre atributele entităţilor si a criteriilor de validare; 

specificarea modului de translatare a modelului logic intern în model fizic intern, a 
metodelor de acces, controlului securităţii şi integrităţii, modelului de alocare 2 
spaţiului de memorare, redundanja proiectată, tipuri de erori ce pot apare, tehnici 
de compactare; 

realizarea schemelor de încărcare, determinarea spaţiilor primare de încărcare; 
determinarea capacităţii de memorare disponibilă; 

determinarea timpului de acces admisibil; 

aprecierea dimensiunii spaţiului de memorare suplimentar necesar in procesul de 
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întreţinere a bazelor de date; 
specificarea formatului datelor de intrare şi a modului de încărcare a acestora; 


ood de proiectare a subsistemului de administrare a bazelor de date se referă 


prolectarea bazal de date pentu stisficerea ceinelor villiztorior și crearea 
i de date asociat acesteia; 
definirea regulilor de utilizare a bazei de date şi restricţiilor de acces; 
proiectarea sistemului de securitate pentru protejarea bazei de date împotriva 
rare pa glad mee 
proiectarea pentru protejarea împotriva impreciziei, i datelor, pentru 
semnalarea datelor suspecte şi pentru adaptarea bazei de date la noile cerinţe; 
proiectarea software-ului pentru întreţinerea bazei de date, reorganizare. 


Funcţiile de asistare la realizarea aplicaţiilor care utilizează baza de date se 


referă la: 


participarea la identificarea cerințelor relative la baza de date pentra aplicațiile 
existente, cât şi pentru cele viitoare, în scopul realizării integrităţii datelor, 

verificarea dacă cerinţele de date ale programelor de aplicaţie noi pot fi satisfăcute de 
baza de date existentă; 

ninga dacă cerințele de rapoarte ale utilizatorilor pot fi satisfăcute de SGBD-ul 
utili: 


imi de monitorizare a utilizării bazei de date constă în 
i, securităţii bazei de date; 
TUARA performanțelor de exploatare. 


Monitorizarea trebuie să includă: 


asigurarea duplicării datelor si păstrarea lor prin utilizarea tehnicilor de 
salvare/restaurare; 

asigurarea integrității bazei de date printr-un control centralizat, validarea tuturor 
datelor de intrare, examinarea periodică a datelor pentru asigurarea corectitudinii 
datelor, pentru actualizarea, modificarea sau ştergerea unora. 

Monitorizarea performantelor bazei de date constă efectiv în: 

statistici relative la timpul de acces; 

frecvenţa citirilor/scrierilor; 

analiza aspectelor legate de tranzacţii şi efectuarea lor; 

mesajele care apar; 

analiza costului de obținere a anumitor date. 


Perfecţionarea performantelor de exploatare a bazei de date se poate face prin: 
optimizarea structurii fizice a bazei de date; 

modificarea dimensiunilor buffer-elor; 

revederea procedurilor de restaurare/salvare. 


Funcţia de asistare utilizator cuprinde activităţi de instruire a personalului tehnic 


privind: 


wi 


conceptele bazei de date; 

terminologia bazei de date; 

structura bazei de date; 

procedee de memorare și regăsire a datelor în baza de date. 
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3.3. Instrumente la dispoziţia administratorului de 
baze de date 
H 
i 


Pentru a realiza funcțiile prevăzute anterior, administratorul bazei de date trebuie să | 
aibă la dispoziţie diferite instrumente ce pot fi independente sau incluse in SGBD. E1 trebuie | 
să dispună de: 

- programe de încărcare ; 
- rutine de reorganizare (pentru reorganizarea conținutului bazei de date, pentru 

recuperarea spaţiului ocupat de datele şterse; T 

- rutine de jurnalizare pentru înregistrarea fiecărei tranzacţii în baza de date şi a 
identificării utilizatorilor care efectuează aceste tranzacţii şi pentru înregistrarea stării 
bazei de date înainte şi după efectuarea acestor tranzacţii; 

- rutine de restaurare; 

-~ rutine de inijializare, editare; 

- rutine de analiză si comparare. 

De exemplu, pentu SGBD-ul ORACLE unele dintre aceste instrumente se | 
coneretizeazà în Export, Import, SQL*Loader etc. i 

Dicfionarul de date este de asemenea un instrument indispensabil pentru organizarea 
colecţiilor de date, reflectarea modului de memorare a acestora şi regăsirea informaţiilor 
referitoare la respectivele date. 

Dicţionarul de date este de fapt o metabază si conţine in general informații despre | 
obiectele din sistem. Este util atât administratorului cât şi utilizatorilor, aceştia putând | 
realiza: | 

-> obținerea de informaţii despre formele de reprezentare a datelor; 

caracteristicele datelor; 
definirea şi structura datelor; 
contextele de utilizare a datele 
legăturile dintre date şi mediu; 
utilizatorii bazei de date. 
Persoanele care se ocupă de administrarea bazelor de date trebuie să posede o foarte 
bună cunoaştere a modului de funcţionarea sistemului informatic care conţine baza de date, 
a conţinutului structurii bazei de date, cunoştinţe tehnice foarte bune deoarece 
implementarea bazei de date necesită un nivel de competenţă ridicat în domeniul gestionării 
datelor. 


3.4. Protecţia bazelor de date 


Protecţia bazelor de date presupune : 
- asigurarea confidenfialit&tii datelor (protejarea împotriva accesului neautorizat la 
date); 
- asigurarea integrității datelor (protejarea împotriva deteriorării conținutului 
informaţional ca urmare a unor defecte de echipament sau erori de program). 
Protecţia unei baze de date este una din sarcinile ini: i baze de date. 


Administrarea bazelor de date 


3.4.1. Asigurarea integrităţii datelor din baze de date 


Asigurarea integrităţii datelor se impune în cazul unor căderi de echipament sau 
software şi se poate realiza prin procedeul copiilor de siguranță sau a fişierelor de urmărire 
(jurnale) cu menţiunea că (figura 3,1.): 

- realizarea fişierelor de urmărire se face de către MONITOR într-o formă decisă de 
administrator ; 

- realizarea copiilor de siguranță si a restaurării se face cu programe utilitare puse la 
dispoziţia administratorului bazei de date. 


Integritatea BD a impus noi abordări în contextul lucrului în rețea şi a apariţiei 
produselor de tip virus. Nu numai căderile de echipamente, ci si acţiunea expresă a unor 
factori distructivi poate pune în pericol existența unor informaţii nealterate în BD. După 
cum se ştie, viruşii informaţiei acţionează asupra BD similar programelor executabile 
obişnuite. Poate fi vorba de viruși generali care se implantează în orice program executabil, 
sau de viruși specifici SGBD. Efectele distructive ale acestora sunt mult mai ample asupra 
BD, comparativ cu cele asupra fișierelor individuale, iar efortul recuperării informaţiilor 
devine colosal. Iată de ce păstrarea unor copii de siguranţă, pe suporturi ferite de acţiunea 
viruşilor şi cu protecție fizică la scriere, se recomandă cu și mai mare acuitate. 

Este contraindicată folosirea unor produse software de proveniență dubioasă, precum si 
dispunerea unei BD pe aceeași partiție de disc unde se află şi produse nespecifice SGBD. Pe 
cât posibil, datele vor fi separate de programe, iar rularea programelor în acces extins asupra 
BD să fie totdeauna supravegheată, evitându-se astfel "imprumutarea' drepturilor de acces, 
unor viruși implantaţi în aceste programe, 

Prezenţa nejustificată și frecvenţa unor sectoare defecte, modificarea lungimii unor 
programe, încetinirea ritmului de lucru cu BD, mesaje de interdicţie a unor accese la BD 
nesolicitate expres de utilizator, reacţii spontane necaracteristice lucrului obişnuit cu o 
bază de date sunt tot atâtea simptome care impun oprirea rapidă a oricărei prelucrări asupra 
BD si declanșarea unor proceduri de salvare. Pentru aceasta se vor folosi numai programe de 
rezerva, aflate pe medii externe despre care se ştie că nu sunt contaminate. 

Folosirea unor produse de devirusare se va face numai când este garantată 
proveniența acestora, întrucât multe din acestea sunt și ele însele viruși. 

Pentru SGBD-urile care permit stocarea programelor atât în cod sursă, cát si în forma 
executabilă, se recomandă doar păstrarea codului sursă, întrucât este cunoscută inapetența 
viruşilor fată de fişierele neexecutabile. Este indicat să înzestrați programele de lucru 
asupra BD cu mesaje privind derularea fazelor, astfel încât să poată fi semnalată orice 
activitate suspectă, desfășurată în paralel cu cea solicitată expres de utilizator. Nu este indicată 
protecţia BD prin produse virus, deoarece în anumite contexte greu de anticipat efectul 
acţiunii lor distructive se poate răsfrânge asupra propriului nostru interes! Nu în ultimul 
rând, măsurile organizatorice vizând instruirea personalului de serviciu, asigurarea 
controlului periodic al activităţii, păstrarea şi controlul folosirii documentelor şi purtătorilor 
de infotmaţii pot contribui într-o măsura hotărâtoare la protecţia fişierelor şi bazelor de date. 
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Fig. 3.1. Tehnici de asigurare a integrităţii datelor 
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3.4.2. Asigurarea confidentialitátii datelor din baze de date 


Pentru o BD, problema confidenfialitàjii devine complexă datorită numărului 
mare de utilizatori, conexiunilor multiple între informaţii, precum şi datorită flexibilităţii de 
interogare oferite de SGBD şi accesului concurenţial, t 

Sunt recunoscute cel puțin patru clase de mecanisme distincte ale asigurării 
confidenţialității datelor : E 

- autorizarea sau controlul accesului, cuprinzând tehnicile de validare a identităţii 
utilizatorilor, înaintea accesului la BD; 

- controlul fluxurilor de date vizând supravegherea căilor de circulaţie a informaţiilor 
în sistem, pentru a evita ca informaţiile să ajungă si la dispoziţia neautorizaţilor ; 

- controlul de inferenţă, prin care se studiază posibilităţile de deducere logică a unor 
informaţii secrete, pornind de la informaţiile la care este permis accesul; 

-  criptografierea, prin care se asigură codificarea informaţiilor pe timpul stocării sau 

transportului, astfel încât numai posesorii parolei pot să le descifreze. 5 

Vom trece pe scurt în revistă aspectele principale care apar în cadrul fiecărei categorii 
de metoda de securizare a BD. 


În cadrul autorizării si revocării unor drepturi de acces problemele care trebuie 

soluționate se referă la: r 

- nivelul la care se aplică: la nivelul întregii BD, a unei relații, doar asupra unor tupluri 
etc.; 

- tipul privilegiilor ce pot face obiectul autorizării/revocării (citire, scriere, modificare, 
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adăugare, ştergere, creare de index, execuția unui program); 

- modul de transmitere a privilegiilor altor utilizatori, de către un utilizator care le-a 
dobândit deja. 

Sc practică sisteme ierarhice sau reţea pentru urmărirea transmiterii drepturilor de 
acces, pentru a evita supercentralizarea puterii sau dobândirea unor drepturi pe mai multe căi, 
ceea ce trebuie cunoscut în momentul unor reorganizări a BD. 

- posibilități de revocare a unor privilegii, cu efecte în lanţ pentru toţi utilizatorii 
autorizaţi de utilizatorul vizat explicit de revocare. 


În esență, controlul fluxurilor de date într-o BD urmăreşte evitarea accesului unei 
persoane neautorizate la o informaţie, prin intermediul altei persoane, care are acces la aceasta 
informaţie si îi face o copie, sustrăgându-se ilității pentru acest act. 

Problema apare datorită faptului că privilegiile le-am atribuit în exclusivitate 
utilizatorilor, deşi ele sunt şi un apanaj al resurselor BD, la care se referă. Dificultatea 
rezolvării este sporită prin faptul că pot exista şi canale secrete de transmitere sau canale 
volatile, de tipul memoriei interne sau terminalelor (informaţiile putând fi preluate nu din 
BD, ci din buffere în momentul în care un utilizator autorizat le accesează sau pur şi simplu 
copiindu-le de pe un ecran în timp ce sunt consultate de persoane îndreptățite să dispună de 
ele). 

Pentru a îmbunătăţi controlul accesului la o BD, va trebui să legăm acest acces nu 
numai de utilizatori şi resurse, ci şi de factorul timp si de diferitele ipostaze în care se 
poate afla o informaţie într-un sistem de calcul. 

Modelele mai complicate de asigurare a confidențialităţii datelor operează cu mai 
multe categorii de obiecte protejate: utilizatori, programe, terminale, fişiere etc., cu clase de 
securitate (nesecret, confidenţial, secret, strict secret, secret de stat) aplicat fiecărei categorii 
de resurse informaţionale, cu tipuri de acces diferențiate (parţial, cu aprobare etc.) si cu o 
mulțime de stări în care se poate afla o informaţie. In aceasta manieră, accesul apare 
definit ca o mulţime de cereri ale utilizatorilor N, pentru operaţiile O, asupra resurselor R, 
într-un moment când sistemul se află în starea S. 

Caracterul secret al informaţiilor depinde și de gradul de agregare. Dacă, spre 
exemplu, informaţiile despre o colectivitate statistică nu au caracter secret, în schimb 
informaţiile despre o persoană din această colectivitate nu sunt de uz public. Indiferent care ar 
fi de sintetizare a informațiilor la nivelul colectivităţii, acestea vor purta totuși în 
ele esență informațiilor elementare din care provin. Rezultă că, oricând, abilitatea unui 
utilizator în deducții logice, poate conduce la obținerea de informaţii confidențiale pornind 
de la informaţii pur statistice. 

Ideea că fiecare cerere este formulată în termenii unor condiţii de selecţie conduce şi 
la posibilitatea ca primind condiţii foarte restrictive să se răspundă cu foarte puţine tupluri 
care le îndeplinesc. Punând o succesiune de întrebări, subcolectivităţilor rămase în discuţie 
Până la un moment dat, pot fi deduse informaţii particulare. Pentru înlăturarea acestei 
posibilități au fost gândite SGBD care nu răspund la cereri în cazul în care rezultatul este sub 
un anumit prag de semnificaţie. Acest prag trebuie înţeles și în sensul complementarităţii, 
deoarece punând întrebări, negaţii ale celor în care este interesat un intrus, răspunsurile 
cuprinzând aproape toți indivizii colectivităţi sunt la fel de 'utile' în deducerea informaţiilor 
secrete, 


Un alt mod de deducere a informaţiilor confidenfiale foarte frecvent folosit se bazează 
pe calcule statistice. Relaţiile existente între caracteristicile cantitative stocate în BD pot 
Permite prin succesiuni de calcule accesul la informaţii certe sau foarte apropiate de cele 
reale. 
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Lupta împotriva unor tehnici de „vânare de informaţii” nu a fost din păcate încheiată. 
Ar trebui practic ca un SGBD să răspundă sau nu la o întrebare şi în funcţie de întrebările la 


care s-a răspuns anterior, lucru foarte costisitor de implementat. Utilizarea unor informaţii | 
parţiale cunoscute din alte surse şi coroborarea lor cu cele fumizate din BD complică şi mai | 


mult mecanismul protejării informaţiilor. 


Problema rămâne deschisă în continuare, ceea ce s-a reuşit până în prezent fiind | 


găsirea unor tehnici de descurajare, prin costul obținerii informațiilor secrete. 

Amintim alte câteva procedee folosite în controlul inferenței: 

- partajarea BD în clase, cu număr critic de elemente, astfel încât nu vor fi niciodată 
furnizate informaţii despre subgrupe, ci doar despre grupă in totalitate. Alegerea grupelor în 
concordantă cu cerinţele informaţionale ridică totuşi destule probleme; distorsionarea voită 
a rezultatelor, pe baza unor distribuții aleatoare, astfel încât informaţiile furnizate să aibă 
doar valoare statistică. Pentru cei autorizaţi însă, rezultatele trebuie să fie exacte, SGBD 
făcând distincţie între categoriile de utilizatori; 

- eşantionarea aleatoare a BD, astfel încât un utilizator neavizat să nu poată obține 
informaţii individuale, ci doar la nivelul unui eşantion, a cărei alegere scapă de sub controlul 
utilizatorului, 


Existenţa multor algoritmi de criptare implementați soft sau hard asigură într-o 
mare măsură securitatea informaţiilor pe timpul stocării sau transportului acestora. Tehnicile 
de criptografiere au cunoscut un avânt nemaiintálnit odată cu exploatarea BD prin reţele de 
calculatoare. De cele mai multe ori aceste tehnici asigură simultan și compactarea 
informaţiilor, contribuind la creşterea eficienței stocării datelor. 
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O multitudine din sistemele de baze de date de astăzi sunt bazate pe modelul relațional 
propus de E.F. Codd în 1970 cu intenția de a pune la dispoziție elementele necesare pentru a 
asigura independența datelor. Un model relational se bazează pe două concepte (figura 4.1): 
"an şi tabelă, care diferă prin natura lor dar care au o puternică legătură prin aceea că: 

noţiunea de relaţie este formală, formalitate dată de proveniența sa din teoria 

matematică a mulțimilor, care a permis definirea unei teorii suport a modelului; 
- noțiunea de tabel care este simplă si intuitivă, conform provenienjei sale din 
span curente, oferind o înţelegere naturală inclusiv utilizatorilor finali. 


„ANEI 
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Fig. 4.1. Relaţia ANGAJAT 


Prezenţa simultană a celor două noţiuni a contribuit la marele succes al modelului relafional. 


4.1. Domeniu, atribut, valoare 


` Un sistem relațional este un sistem in care: 
- datele sunt percepute de utilizatori ca tabele; 


—— 


- operatori utilizați pentru manipulare (de exemplu, regăsire) sunt operatori care 

generează noi tabele pornind de la cele existente. 

Cea mai mică unitate de date manipulabilă în modelul relațional este valoarea 
individuală, adică valoarea considerată atomică prin faptul că este nedecompozabilă. O valoare 
este considerată nedecompozabilă dacă nici unul din algoritmii care o prelucrează nu utilizează 
părți ale sale cu un înţeles anume. De exemplu dacă avem valoarea 05051987 care este o dată 
de naştere (zi, lună, an) atunci această valoare este o dată atomică dacă nu avem nevoie, pe 
parcursul utilizării sale, numai de unul din elementele care o compun (de exemplu an) ci o 
utilizăm ca atare, ca un tot. 

Definiția relației, prin teoria matematică a mulțimilor pe care se bazează, face apel la 
două concepte de bază: domeniu si atribut. Un domeniu (D) este definit ca mulţimea obiectelor 
de acelaşi tip. Semnificaţia domeniului este următoarea: dacă două sau mai multe atribute 
primesc valori din același domeniu atunci sunt admise şi au sens operaţiile de comparare (şi alte 
operaţii ca joncțiune, proiecţie etc.) între aceste atribute (despre atribute putem spune că sunt 
semantic comparabile). Un atribut (4;) reprezintă o interpretare anume a obiectelor domeniului. 
Deoarece fiecare definire de atribut (4) trebuie să conţină o referire la domeniul corespondent, 
la definirea bazei de date este necesară specificarea (ca parte componentă a definirii bazei de 
date) tuturor domeniilor identificate în faza de analiză a sistemului. 

De exemplu, în figura 4.1 domeniile sunt MĂRCI, NUME, SEX, DATE, SALARII, 
FUNCȚII, LOCURI_DE_MUNCĂ. Aceste domenii pot fi considerate domenii specifice ale 
relaţiei. La aceste domenii avem asocierile de atribute evidenţiate în figură. 

Dintre aceste asocieri putem distinge atributele NR#, si SOT şi ŞEF care iau valori din 
acelaşi domeniu MĂRCI. Denumirile diferite ale atributelor ne dau semnificația valorilor din 
doemniul MĂRCI astfel: 

- NR4, este marca (sau codul numeric personal - CNP) unui ANGAJAT; 

- SOT, în cazul în care în tabelă (relaţie) sunt înregistrate și datele soțului (soţiei) va 

conţine marca acestuia (acesteia); 

- ŞEF, marca șefului fiecărui angajat. 

Domeniile identificate în figura 4.1 pot fi generalizate prin tipurile de mulțimi 
matematice din ci be valori astfel: 

-  Întregi:MĂRCI, SALARII, LOCURI_DE_MUNCĂ, ŞEF; 

- Şiruri de caractere: NUME, SEX, FUNCȚIE; 

= Date calendaristice: DATE. 

În acest context fiecare domeniu este o mulțime infinită, mulțime care nu poate fi 
stocată în practică pe calculator care are resurse finite. Din aceste considerente domeniul de 
definiție a atributelor poate fi considerat o submulțime a domeniilor generalizante din care fac 
parte. Specificarea practică a domeniilor generalizante este efectuată în practică prin asocierea 
unui tip de dată fiecărui atribut sau prin definirea subdomeniilor. Definirea practică a 
domeniilor specifice este efectuată prin asocierea la fiecare atribut a unor restricţii sau 
constrângeri cum ar fi apartenența la un interval de valori, listă de valori posibile, date 
calendaristice minime etc. 

figura 42 domeniile sunt COD UNITÁTL MNEMONICE JUDEŢE, 
DENUMIRI UNITÁTI, ADRESE, TELEFOANE. La aceste domenii avem asocierile de 
atribute evidenţiate in figură. Dintre aceste asocieri putem distinge atributele JD şi JUD care au 
aceeaşi interpretare semantică dar iau valori din domenii diferite. 

Domeniile diferite pe care sunt definite atributele introduc restricţii de integritate 
diferite, la definire şi utilizare, astfel: 

- JD este codul de identificare a unui JUDET şi este cuprins în intervalul [01,47]; 

- JUD este codul mnemonic al judeţului care lua valori numai dacă este unul 

dintre elementele listei: (AB, AR, AG, B, BR, BV, ..., VN). 
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Fig. 4.2 Relaţia DJDP (Direcţii Judeţene de Drumuri si Poduri) 


În figura 4.3 este prezentat tabelul (relaţia) Jurnal_Curent care confine înregistrarea 
rulajelor (parțial) contabile aferente lunii 10 a anului 1999 si în care coloanele definite au 
semnificaţia: 
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Fig. 4.3. Relaţia Jurnal Curent 
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-  PozDoc: poziţia înregistrării în documentul justificativ; 

- Nota: numărul notei contabile în care se consemnează înregistrarea; 

-  NrDoc: numărul/felul documentului intern; 

- Zi, Luna, An: data înregistrării (prinderii) în contabilitate a operației; 

- ContDB: simbolul contului care se debitează cu valoarea operaţiei contabile; 

-  ConiCR: simbolul contului care se creditează cu valoarea operaţiei contabile; 

- Valoare: valoarea (suma) înregistrată; 

-~ Obs: explicaţii privind operaţia; 

- . Provenienya: proveniența rulajului (subsistemul din care provine); 

-  Datint: data operării (introducerii) la calculator a operaţiei; 

- NrDocExt: numărul documentului atribuit de către emitent; 

- TipDoc: felulfipul documentului; 

-  DataDoc: data emiterii documentului de către emitent. i 

În acest tabel atributele (coloanele) ContDB şi ContCR sunt definite in același domeniu 
denumit "Simboluri Conturi” domeniu format din multitudinea simbolurilor de conturi sintetice 
sau analitice ale unei întreprinderi, simboluri care trebuie să se regăsească în "Planul de 
Conturi" al acesteia. Combinația ContDB-ConiCR defineşte formula contabilă a înregistrării. 
Aceste atribute reprezintă o interpretare semantică a domeniului, dată de poziţia lor în formula 
contabilă, astfel: | 

= ContDB reprezintă simbolul contului care se debitează în cadrul operaţiei contabile; 

~ ContCR reprezintă simbolul contului care se creditează in cadrul operaţiei contabile. 


4.2. Relatie, tuplu 


O relaţie R pe domeniile Dj, Da .. D, (nu neapărat distincte) constă dintr-un cap (de 
tabel) şi un corp (de tabel), Capul relației (tabelului) constă dintr-o mulţime fixă de atribute 
(coloane) 4j, 4... An astfel încât un atribut (o coloană) A, corespunde exact unui singur 
domeniu D, cu i=1,2,..„n. Fiecărei relaţii i se atribuie o «demumire de relafie»- 

Fiind dat un număr n>1 de domenii Dj, Dz .. D, (nu neapărat distincte) o relaţie R 
definită pe aceste domenii este o submulțime a produsului cartezian al acestor domenii, adică 
ReDyixDx..xD, 

Asocierea denumirii de relaţie cu denumirile atributelor componente se numeşte schema | 
relaţiei (sau schemă de definire) notată în mod uzual ca &(4;.45..,4,) sau dacă X este este | 
mulțimea de atribute a lui R, adică X-(4;.45... A), atunci relaţia poate fi notată ca R(X). Dacă | 
t este un tuplu pe X si A este un atribut al său, ACX, atunci prin notația //47 sau £4 vom indica | 
valoarea tuplui t pentru atributul A (poate fi un singur atribut sau o mulțime de atribute). În cele | 
ce urmează prin notafiile de tipul R() vom desemna schema de relație a relației R pe mulțimea 
atributelor X. | 

Pentru exemplul din figura 4.1 schema relației cu denumirea ANGAJAT este: | 
ANGAJAT(NRI, SOT, NUME PRENUME, SEX, DATA NASTERII, SALARIU, FUNCŢIE, | 
LOC_MUNCĂ, ŞEF), în paranteză fiind indicată intensia (capul) relaţiei. 

Relaţia ANGAJAT este definită pe produsul cartezian al domeniilor: 

a MÁRCI x NUME x SEX x DATE x SALARII x FUNCŢII x LOCURI DE. MUNCA x | 
CI 


sau, generalizând, pe produsul cartezian ÎNTREGI x ÎNTREGI x SIR DE CARACTEREx | 
SIR DE CARACTERE x DATE x ÎNTREGI x SIR DE CARACTERE x DATE x ÎNTREGI x 
ÎNTREGI 


Pentru exemplul din figura 4.2 schema relaţiei cu denumirea DJDP este: 
DIDP(DRDP, JD, JUD#, DJDP, ADRESA, TELEFON). 

Pentru exemplul din figura 4.3 schema relaţiei Jurnal. Curent este: 
Jurnal. Curent(PozDoc, Nota, NrDoc, Zi, Luna, An, ContDB, ContCR, Valoare, Obs, 
Proveniența, Datint, NrDocExt, TipDoc, DataDoc). 

Schema relației reprezintă intensia relației. De exemplu schema relaţiei (tabelei) pentru 
Planul de Conturi poate fi definită ca Plan_de_Conturi(Simbol, Descriere, Func), cu: 

- Simbol: simbolul contului; 

- Descriere: denumirea contului; 

- Func: func[ionalitea contului. 


Pentru Balanța curentă schema poate fi definită ca Balanta(An, Luna, Simbol, Dblan, 
Crlan, DbPrec, CrPrec, DbLuna, CrLuna) cu: 

- An: anul balanței; 

- Luna: luna balanței; 

- Simbol: simbolul contului; 

-  Dblan: sold debitor la început de an fiscal (Ianuarie); 

-  Crlan: sold creditor la început de an fiscal (Ianuarie); 

- DbPrec: sume debitoare precedente (sume debitoare cumulate ale perioadelor 
precedente adică între Ianuarie din anul An şi luna curentă Luna); 

-  CrPrec: sume creditoare precedente (sume creditoare cumulate ale perioadelor 
precedente adică între Ianuarie din anul An şi luna curentă Luna): 

- DbLuna: sume debitoare în luna balanței; 

- CrLuna: sume creditoare in luna balanței. 


Corpul relaţiei (tabelei) constă dintr-o mulţime de tupluri (rânduri, înregistrări, linii) 
variabilă în timp (se pot adăuga noi rânduri, se elimină sau modifică cele existente). O 
instanță a relaţiei (sau simplu o relaţie) pe schema RX) este o mulțime r de tupluri pe X. Prin 
notația r(X) sau r vom desemna o instanţă a relaţiei R pe mulțimea de atribute X (mulţimea 
tuplurilor pe X la un moment dat). De exemplu pentru "Balanța Curentà" putem să adăugăm 
conturi noi analitice (este posibilă de fapt adăugarea oricărui tip de cont) în orice moment sau 
putem să eliminăm acele conturi care au sumele 0 (zero) timp de doi ani la rând. 

Rândurile  (tuplurile) constau dintr-o mulțime de perechi de tipul 
(denumire_atribur:valoare), adică o mulțime de forma ((4;:V)), î=1,2..n). Pentru fiecare 
atribut (coloană) A; din schema relaţiei (capul de tabel) există o astfel de pereche. Pentru fiecare 
pereche (A; V) aflată în mulţime, V, este o valoare din domeniul unic D, asociat cu atributul Aj 
Altfel spus, un rând (tuplu) 1<vp,Va....Y> aparține relaţiei r dacă şi numai dacă vr eDOM.A;, 
WEDOM 4a,... DOM Am, unde prin DOM.A, am notat domeniul la care este asociat atributul 
A, (deoarece domeniile nu sunt obligatoriu distincte această notație este mai sugestivă). 

De exemplu, tuplul marcat în figura 4.2 este «03,03, AG, ARGEŞ, PITEŞTI, 734327> şi 
îndeplineşte condiția de apartenenţă a valorilor la domeniile de definire: 

+ 03eDOM.DRDP (CODURI JUDEŢE), 

03eDOMJD (CODURI JUDEŢE), 
AGeDOMJUD (MNEMONICE, JUDEŢE), etc. 


Numărul de atribute al unei relații se numește gradul relației. De exemplu relaţia 
ANGAJAT din figura 4.1 are gradul 9, relaţia DJDP din figura 4.2 are gradul 6 iar relația 
Jurnal. Curent are, conform schemei sale de relaţie, gradul 15. 

Numărul de rânduri (tupluri) al relaţiei se numește cardinalitatea relaţiei. Cardinalitatea 
unei relaţii 7 va fi desemnată prin |r|. De exemplu relația ANGAJAT din figura 4.1 are 


cardinalitatea 7 în timp ce relația Jurnal Cureat din figura 4.3 are cardinalitatea 19 (vezi 
indicaţia Records). 


Corpul relației (tabelului) reprezintă extensia relaţiei. Prin aceste definiţii am furnizat | 


cadrul formal al noţiunilor de relaţie, tuplu si atribut, utilizate in modelul relational. 

Utilizatorii, datorită diversităţii lor, percep si folosesc aceste noţiuni în următoarele 
acceptiuni informale (exceptând, eventual, utilizatorii speciali ca administratorul bazei de date - 
ABD - şi programatorii de sistem): relaţia este un tabel, tuplul este o înregistrare sau un rând al 
tabelului, iar atributul este un câmp din înregistrare sau o coloană a tabelului. În principiu, 
gradul relaţiei este o mărime constantă (adăugarea de noi atribute la o schemă de relaţie se 
execută foarte rar) pe când cardinalitatea este o mărime variabilă în timp. 

Deoarece corpul tabelului (relației) este o mulțime relația (tabelul) are următoarele 
proprietăţi invariante în timp: 

~ Nu sunt admise rânduri (tupluri) duplicate (identice); 

- Rândurile sunt neordonate (de sus în jos); 

~ Coloanele (atributele) sunt neordonate de la stânga la dreapta; 

- Toate valorile atributelor sunt atomice. 

Aceste proprietăţi pot fi interpretate, în cadrul sistemului financiar-contabil, astfel: 

~ În Balanța de Verificare sau Planul de Conturi nu trebuie să avem două conturi cu 
același simbol; în Jurnal nu trebuie să înregistrăm de două (sau mai multe) ori 
operaţiile (rulajele) aceluiaşi document; 

- Adăugarea de noi conturi în Planul de Conturi sau în Balanța de Verificare nu 
necesită reorganizarea acesteia deși conturile trebuie să apară în liste în ordinea 
crescătoare a valorii simbolurilor lor. Acestea vor fi adăugate la sfârșitul tabelului, 
iar la listare vor fi aranjate, prin posibilitatea de reordonare pusă la dispoziţie de 
limbajul de manipulare, conform cerinţelor utilizatorului. Similar orice înregistrare 
în jurnal va fi efectuată în ordinea operării sale la calculator. Această proprietate 
ne asigură că nu putem să realizăm intercalári sau inserări permițând astfel 
respectarea interdicfiei prevăzute de legea contabilităţii; 

- Coloanele din tabelă pot fi aranjate conform oricăror necesităţi tehnice iar la 
interogarea (Consultarea) bazei de date acestea pot fi arânjate conform 
specificaţiilor din lege sau ale utilizatorului; De exemplu data înregistrării în 
contabilitate a rulajului este dată sub forma Zi, Luna, An ceea ce ne permite 
efectuarea directă de listări aferente unei zi anume lucru cerut în mod expres 
pentru Registrul de Casă şi Jurnal de Bancă prin legislaţie. 


Descrierea în SQL a intensiei relațiilor este realizată prin intermediul comenzii 
CREATE TABLE a limbajului de definire. De exemplu crearea tabelei Plan_de Conturi poate 
fi exprimată în SQL astfel: 


CREATE TABLE Plan_de_Conturi 
(Simbol TEXT(22) NOT NULL, Descriere TEXT(60), Func TEXT(1)) 


4.3. Relaţii şi baza de date 


Relaţiile pot fi utilizate pentru a organiza datele relevante ale unei aplicaţii. În general 
nu este suficientă o singură relaţie pentru a realiza acest lucra ci o mulţime de relații ale căror 
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tupluri (rânduri) conţin valori comune necesare stabilirii corespondenţei între acestea, mulțime 


formează o bază de date (figura 4.4). 1 Le 
SEU end Dee de dl Juni ciao mine desde Gorda cu diee demi 
licá B={R (X), RAX), -Ra Xa) 
Da eta a bazei de date (sau baza de date — database) pe schema B«(Ri(X), 
RAX3), Rally) este mulţimea relațiilor bfrj ra...) unde fiecare r, cu 1SiSn, este o relație 


b Schema bazei de date, pe care o vom denumi SALARII, corespunzătoare instanței din 
figura 4.4 este SALARII(ANGAJAT(CNP, Sot, Nume, Prenume, Sex, Profesia, Data naşterii, 
Funcție, Telefon, Şef. Salariu), PROFESII(Cod Profesie, Profesie), FUNCŢII(Cod Funcție, 
Funcie)). Caracteristica esențială a unei baze de date relafionale este reprezentată de faptul că 
referirile dintre diversele relaţii (tabele) sunt reprezentate prin semnificaţia valorilor din 
domeniu care apar în tuplu (rând). De exemplu, în relaţia ANGAJAT valoarea atributului Sop 
din rândul trei a angajatei Ionescu Maria este egală cu valoarea CNP a angajatului Ionescu 
Claudiu iar a acestuia cu cea a angajatei lonescu Maria definind astfel relația de căsătorie dintre 
cei doi angajaţi. Similar coloanele Funcție şi Profesia din tabela ANGAJAT iau valori din 
coloana Cod Funcție a tabelei Funcţii, respectiv coloana Cod Profesie a tabelei Profesii. 


Fig. 4.4. Exemplu de instanţă a bazei de date 


Structura modelului relational se dovedește, prin prisma celor prezentate anterior, foarte 
simplă şi puternică. În petes acesta impune un anumit grad de rigiditate: informaţia 
trebuie reprezentată prin tupluri de date adică ni se impune, în fiecare relație, să reprezentăm 
numai tupluri care corespund schemei sale. Dacă analizăm relaţia ANGAJAT din figura 4.4 aici 
avem un atribut SOT ale cărui valori sunt luate din domeniul CNP şi reprezintă faptul că un 
angajat este căsătorit cu un alt angajat. Dar, pe de o parte nu toţi angajaţii sunt căsătoriţi iar, pe 
de altă parte chiar dacă sunt căsătoriţi nu este obligatoriu să avem toate cuplurile printre angajați 
ceca ce ne duce la ideea că această informatie nu este disponibilă pentru toti angajaţii. Domeniul 
CNP din care ia valori atributul SOT contine numai coduri numerice peronale, deci valori 
concrete. Pentru a putea reprezenta informaţiile indisponibile conceptul de relaţie a fost extins 
pentru a include posibilitatea ca un tuplu să pentru fiecare atribut fie o valoare dintr-un 
domeniu fie o valoare specială denumită valoare nulă (null value). 
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“Valoarea nulă (nu zero) specifică absența informaţiei si reprezintă o valoare adițională 


de bază Şi (And), Sau (Or) şi Nu (Not) sunt prezentate în tabelul 4.1. 


or logice cu tratarea valorii Noll 
DE z 


A — Adevărat (True); 

F — Fals (False); 

N — nul (cu sensul de Null, indisponibilá - Unavailable, nedefinită — 
Undefined). 


Pe baza aeeaiei de adedi er bt defi dosi api forme de conditi simis cael 
verifică dacă valoarea specificată este Null astfel: 
E Tcu Null esie evan Ja AGAM po ud ct Beca aldea hiit pe tt A ] 

este Null si la Fals in caz contrar; 

~ A Is Not Null este evaluată la Adevărat pe un tuplu t dacă valoarea lui t pe atributul | 

A provine din domeniul lui A nulă şi la Fals dacă valoarea este Null. 


4.4. Restricţii de integritate 


Restricfiile (constrângerile) de integritate reprezintă proprietăți care trebuie să fie 
satisfăcute de către toate instanțele corecte ale bazei de date. O constrângere trebuie percepută 
ca un predicat care are valoarea Adevărat sau Fals pentru fiecare instanță. Ele sunt definite în 
general sub formă de expresii logice (simple sau complexe) dar nu sunt excluse nici definirile 
care implică calcule complexe exprimate pe mai multe coloane. În general unei scheme de bază 
de date i se asociază o colecţie de constrângeri, iar instanţele bazei de date care le satisfac sunt 
considerate corecte. În funcție de elementele bazei de date cărora li se asociază constrângerile 
pot fi clasificate în: H 

- constrângeri intra-relafie dacă respectarea lor implică numai o relaţie a bazei de 

date. Acest gen de constrângeri pot fi clasificate astfel: H 

LI suetrictl I nivel do tupia cere sunt evaluate Independent pentru. ficare tupla i 
sunt definite pe valorile fiecărui tuplu independent de altele; B 

" AP d EI E MA 
restricţii pe domeniul atributului; 

o restricții la nivel de tabelă care se aplică pe valori care apare în mai multe tupluri 
ale relaţiei; 

- constrângeri inter-relafie dacă acestea implică mai mult de o relaţie. 


4.5. Chei 


Deoarece corpul unei relaţii este o mulţime, iar prin definiție mulțimile nu conțin 
elemente duplicate (dubluri), rezultă faptul că nu avem, la orice moment, două sau mai multe 
rânduri (tupluri) identice. Acest lucru ne permite să tragem concluzia că există un atribut sau o 
combinaţie de atribute ale cărui (căror) valori identifică în mod unic rândurile (tuplurile). 
Această proprietate trebuie îndeplinită cel puțin de combinaţia atributelor care compun întreg 
rândul (tuplul). Evident nu este exclusă nici posibilitatea existenţei mai multor atribute sau 
combinaţii de atribute care să realizeze identificarea unică a fiecărui rând (tuplu). 

Dacă r este o relație cu atributele 4; 4.....4, atunci mulţimea de atribute C=(444p....4m) 
este candidat pentru cheie a lui R dacă şi numai dacă satisface următoarele două proprietăți 

de timp: 

-  Unicitate care precizează că nu există, în orice moment, două rânduri (tupluri) 

distincte din r care să aibă aceeaşi valoare pentru C; 

-  Minimalitate care precizează că nu putem elimina nici unul din atributele 4, 4;..... 4c 

ale lui C fără a pierde proprietatea de unicitate, 


O definiţie alternativă a conceptului de cheie foloseşte noţiunea de superchcie: 

- mulțime de atribute C-(4,4,... Ai) este supercheie pentru o relaţie r dacă r nu poate 
conţine două tupluri 1 şi 12 pentru care tj[C] -t[C]; 

- o mulţime de atribute C=(4,4,...„44) ale unei relaţii r este o cheie pentru pentru r 
dacă este o supercheie minimală (adică dacă nu există o altă supercheie C'a lui r 
care este conținută ca submulțime în C). 


Cu această definiţie putem concluziona că fiecare relație are cel puțin un candidat la 
cheie deoarece cel puțin combinația tuturor atributelor rândului (cuplului) are proprietatea de 
unicitate. 

Pentru exemplul din figura 4.1 avem două chei candidat NR# (care reprezintă marca 
angajatului) şi cheia formată din combinarea atributelor (NUME PRENUME, SEX, 
DATA_NAŞTERII). Pentru exemplul din figura 4.2 avem trei chei candidat DRDP, JD si JUD, 
iar pentru exemplul din figura 4.3 avem cheia candidat formată din combinaţia de atribute: 
(PozDoc, Nota, NrDoc, Zi, Luna, An, ContDB, ContCR, NrDocExt, TipDoc, DataDoc). 


Pentru fiecare relație un candidat la cheie va fi desemnat (arbitrar, dar de obicei luând in 
considerare minimaliatea) pentru a fi cheia primară. 

Pentru modelul relational cheia primară este un element extrem de important deoarece 
reprezintă modul de adresare la nivel de rând (tuplu). 

Pentru exemplul din figura 4.1 atributul NR (marca) a fost desemnat pentru a fi cheie 
primară, iar pentru cel din figura 4.2 JUD? (indicativ judet). Pentru exemplul din figura 4.3 
Singurul său candidat la cheie va fi desemnat drept cheie primară. În cazul în care aceasta nu 
convine se poate introduce o coloană suplimentară de tip autoincrementabilă (COUNTER, 
AUTONUMBER) care poate forma cheia primară numai dacă capacitatea sa de reprezentare 
(de regulă este implementată de SGBD-uri la capacitatea de 27-1) este acoperitoare pentru 
necesarul de rulaje ale unei luni. 

Pentru Balanja şi Plan_de_Conturi candidatul la cheie este reprezentat de atributul 
Simbol şi cheia primară devine acest atribut, care îndeplineşte restricțiile de unicitate și 
minimalitate. Restricţia de unicitate a simbolului de cont este definită expres de Legea 
Contabilităţii numărul 82/1991. De exemplu, la crearea tabelei Plan de Conturi declaraţia de 
Cheie primară se poate exprima în SQL astfel: 


CREATE TABLE Plan_de_Conturi (Simbol TEXT(22) CONSTRAINT 
cheie plan conturi PRIMARY KEY, Descriere TEXT(60), Functionalitate TEXT(1)) 


O bază de date relafionalá poate fi definită, in intensie, printr-o schemă relafionalà care 
constă din una sau mai multe scheme de relaţie. În extensie, baza de date relational este 
pertepibilà ca o colecjo de tabele, ficere tabelă fd copus din rinduri: (denumite si linii 

i) şi coloane (denumite si atribute sau câmpuri) conform modului ilustrat in 
ra 4.2 şi 4.3. În aceste condiţii schema relaţională nu reflectă, explicit, toate asocierile 
între relaţiile din baza de date. Anumite tipuri de asocieri sunt conţinute numai implicit prin | 
propagarea cheii de la o schemă de relaţie la alta. 

Pentru materializarea asocierilor dintre schemele de relație se utilizează noţiunea de 
cheie externă, definită ca un atribut (câmp) sau combinaţie de atribute (câmpuri) dintr-o relație 
(tabelă) ale cărei (căror) valori sunt definite pe aceleași domenii cu cele ale cheii primare din alt 
tabel (sau același tabel). De exemplu, in figura 4.1 avem cheile externe SOT si ŞEF, care isi iau 
valori din domeniile MĂRCI din care ia valori cheia primară NRÁ. 

Tabela Jurnal_Curent conţine două chei externe ContDB si ContCR ambele putând lua 
valori din domeniul format din valorile coloanei Simbol din tabela Balanja. Această proprietate 
a simbolului de cont debitor (ContDB) si a celui de cont creditor (ContCR) este dată de modul 
de definire a formulelor contabile: o formulă simplă debitează un cont şi creditează, în același 
timp, un alt cont ambele conturi trebuind să existe în balanța curentă a întreprinderii (si de altfel 
în Planul său de conturi). 

Pentru a face distincţie între relaţiile stocate în baza de date şi cele obţinute prin 
aplicarea operatorilor relafionali primele tipuri de relaţii se numesc relații de bază iar cel de-al 
doilea relaţii derivate. De exemplu, pentru sistemul financiar-contabil tabelele Plan de Conturi, 
Balanța și Jurnal_Curent reprezintă tabele de bază în timp ce o tabelă cu rulajele unei note 
contabile anume, cum ar fi nota Casa, extrasă din Jurnal. Curent, reprezintă o tabelă derivată 
utilizată temporar. 


Fie R o relaţie de bază cu cheia primară C^(4;,45..../4,), n>0. Fie S o relaţie de bază (R 
şi S nu neapărat distincte) şi fie Bj,B5..,B, atribute din S care satisfac restricţiile de 
independenţă de timp. Pentru orice înregistrare s a lui S în care este îndeplinită una din 
condițiile: 

7 5.85. Bauu+,5. Ba sunt toate nule; 

~ există o înregistrare r a lui R astfel încât r.A/=s.By,r.A2=s.Ba...„r.An=s. Ba: 

- combinaţia (B1,Ba,....B, este o cheie externă în S care este identică cu cheia primară 

(A142... An) din R. 
unde prin construcțiile de forma r. 4, am desemnat valoarea atributului A, din relaţia r. 


: De exemplu declararea asocierii unui cont din Balanța curentă cu contul din 
Plan_de_Conturi poate fi realizată astfel: 


CREATE TABLE Balanta(An SHORT, Luna BYTE, Simbol TEXT (22) CONSTRAINT 
este contul REFERENCES Plan de Conturi (Simbol), Dblan DOUBLE, Crlan 
DOUBLE, DbPrec DOUBLE, CrPrec DOUBLE, DbLuna DOUBLE, CrLuna 
DOUBLE) 
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4.6. Restrictii de integritate minimale 


Fiecare cheie primară si cheie externá din relaţiile (tabelele) bazei de date trebuie să 
satisfacă următoarele restricții de integritate [C.I. DATE, /21; 22; 23/]: 

- integritatea entității (entity integrity): 
Niciun atribut care participă la formarea cheii primare a unei reli de bază nu 
poate primi valori nule”; 

-integritatea referenfiala (referential integrity): 
Dacă o relaţie ra include o cheie externă C, pe cheia primară Cy a relației r; (r; şi 
ra nu neapărat distincte) atunci fiecare valoare a cheii C, din rz trebuie să fie egală 
cu valoarea lui C, dintr-un tuplu al lui r; sau să fie nulă. 


*) Notă! Termenul null nu defineşte valoarea zero (0) ci o valoare specială considerată de 
sistem Null (cum ar fi zero binar). 


Declarația restricţiilor de integritate este efectuată prin asocierea la definiția de coloană 
a clauzei NOT NULL sau prin asocierea unor clauze CONSTRAINT fie la nivel de coloană fie la 
nivel de tabelă (pentru coloane multiple). 

De exemplu, dacă ne referim la tabela Jurnal a cărei cheie primară este formată din 
următoarea combinaţie de atribute (PozDoc, Nota, NrDoe, Zi, Luna, An, ContDB, ContCR, 
NrDocExt, TipDoc, DataDoc) atunci crearea tabelei Jurnal ar trebui să arate astfel: 


CREATE TABLE Jurnal(PozDoc COUNTER, Nota SHORT NOT NULL, NrDoc 
TEXT(16) NOT NULL, Zi BYTE NOT NULL, Luna BYTE NOT NULL, An SHORT 
NOT NULL, ContDB TEXT(22) NOT NULL, ContCR TEXT(22) NOT NULL, Valoare 
DOUBLE, Obs TEXT(60), Proveniența TEXT(6), Datint DATETIME, NrDocExt 
TEXT(16) NOT NULL, TipDoc TEXT(16) NOT NULL, DataDoc DATETIME NOT 
NULL) 


În acest context relaţia 7> este o relație care referă (fiu sau membru-member), iar relaţia 
7; este o relaţie referită (tată sau posesor-owner). 


Justificarea primei reguli de integritate este următoarea: 

- relațiile (tabelele) corespund entităţilor din lumea reală; 

- entitățile din lumea reală sunt distincte (ele sunt identificate in mod unic într-un 
anume fel); 

- cheia primară realizează funcția de identificare unică în cadrul modelului relational; 
pentru a-şi realiza funcția cheia primară nu poate avea valoare nulă. 

ceea ce priveşte cea de a doua regulă de integritate justificarea este următoarea: 

- dacă un tuplu f; referă un tuplu 4, atunci tuplul t; trebuie să existe (de exemplu, dacă 
un rulaj referă conturi din balanța atunci aceste conturi trebuie să existe); 

- dacă valoarea unei chei externe nu este nulă atunci ca trebuie să se regăsească 
printre valorile cheii primare ale tabelei referite. 
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Capitolul 4 


Baze de date relajionale 


4.7. Baza de date relationalá — o descriere formală 


Formal un sistem relaţional este compus din: 
- bază de date relaţională; 

- o colecție de operatori relaţionali; 

- două reguli de integritate; 

- omuljime (set) de asocieri. 


O bază de date relafionali constă dintr-o mulţime de domenii şi o mulţime de relații 
peste care se aplică o mulțime de asocieri. 


Poss notația BNF putem descrie formal baza de date relaţională astfel: 
<bază de date relaţională>::><mulțime de asocieri> (<mulţime de domeni, 
<mulțime de relafii») 

- «muljime de asocieri>::=<asociere>/<asociere> <mulțime de asocier?> 

* <asocieri>::= <asociere atribute>|<asociere relafit» 

-  <asociere atribute> ::= «relafie» 


Fiecare relaţie, din mulţimea de relații, este un rezultat al asocierii atributelor la atributul 
(sau grupul de atribute) desemnat cheie primară a relaţiei. De fapt, atributele care nu participă la 
formarea cheii primare nu reprezintă altceva decât caracterizanji ai cheii. 

Prin asocierile dintre relații (<asociere relații>) se pun în evidență legăturile de” 
interdependenjintercondifionare a fenomenelor sau obiectelor modelate. i 

O asociere între două relaţii si s (nu neapărat distincte) se defineşte într-o direcție dată 
(de la ...| la...) si oferă un mecanism de acces prin care pornind de la o realizare (un tuplu) t al 
lui z avem acces la realizările (tuplurile) t;, tz .... t, ale lui s care îi sunt asociate. 

Deci asocierea este o relaţie binară între două mulțimi (relaţii) r şi s, nu neapărat 
distincte. 


Vom nota asocierea, sub formă funcional, prin rs in care și G sunt func, în 
general multivaloare si inverse una alteia. Asocierea este caracterizată de tipul fiecărei funcții. 
Asocierea poate fi, în funcție de: 

- rezultatul evaluării: 

e monovaloare: dacă evaluarea sa produce o singură valoare; 
o multivaloare: dacă evaluarea sa produce o mulţime de valori. 

Pentru aceste funcții un element caracterizant important este reprezentat de 

cardinalitatea minimală si maximală (numărul minim şi respectiv maxim de valori produse). 


- acu poor asocierii: 
e parțială: dacă există elemente (tupluri) în mulţimea de plecare care nu au o 


imagine în mulțimea destinaţie; 
* totală: dacă toate elementele (tuplurile) mulțimii de plecare au o imagine în 


mulțimea destinaţie. 


PEE bei ce x NEQUE TEVRAT at aoii ede 


perceperii lor, pot fi de tipul : 
- implicite, in uzul asocierilor binare ale atributelor Ja entitatea/relafia cirea Si 


descrie proprietăţile; 


en 


explicite, în cazul în definirii relaţiilor de asociere (ca relaţii independente sau ca 
relaţii normale) prin mecanismul <cheie externă> - <cheie primară>; 

transparente/virtuale, în cazul în care realizarea unei asocieri este determinată la 
"moment" şi în general urmează unui proces de transformare a datelor. După 
realizarea asocierii şi efectuarea operaţiilor care o solicită, asocierea nu va avea 
materializare în baza de date. Realizarea asocierii, la alt moment de timp dar cu 


păstrarea condiţiilor iniţiale, presupune parcurgerea acelorași transformări. ale 


datelor. Acest gen de asocieri au un 
caracter dinamic imperativ ceea ce face ca 
ele să nu poată fi consemnate ca valori ale 
unor atribute de tip <cheie externă>. Acest 
lucru nu înseamnă că asocierile de tip 
cheie externă> mu au un dinamism 
propriu. Diferența constă în faptul că 
asocierile de tip «cheie externă> au un 
caracter relativ stabil, iar materializarea 
este realizată prin existența unei x 
pentru un atribut sau combinaţie de 
atribute care defineşte «cheie externă>. Aceste asocieri sunt materializabile numai 
prin tipul de legătură 1-1 sau 0-1. 


dag 


Primele două tipuri de asociere sunt materializate în relaţii (asocieri reale) care pot fi de 
oricare din tipurile identificate şi pot avea existenţă reală sau virtuală. 

Referitor la asocierile enunțate se pot formula următoarele observaţii pentru cazul 
organizării datelor în baze de date distribuite: 


toate tipurile de asocieri ale unei baze de date locale pot fi identificate şi în baza de 
date globală si deci implicit pot face obiectul descompunerii; 

asocierile de tip virtual pot fi realizate la distanță iar descompunerea se referă la 
faptul că decompozabile sunt numai relaţiile între care apar; 

asocierile explicite care au asociat un index (o cale de acces definită pe cheia externă 
şi o modalitate de specificare a restricțiilor de integritate) impun restricția ca acest 
index sa fie descompus orizontal în raport cu cheia externă (nu cste admisă 
descompunerea verticală a cheii externe formate din combinaţie de atribute). Indexul 
definit reprezintă calea prin care o cheie externă multiatribut este văzută ca un 
întreg. 


Specificând la fiecare funcție F şi G cardinalitatea maximală (n) (notată cu F(h), 
respectiv G(n) vom avea următoarele tipuri de asocieri: 


"unu. la. unu" (1-1): această asociere (one to one) se reprezintă grafic (Bachman) 
ca in figura 4.5. O asociere de tip 1-1 poate fi văzută și ca 0-1. De exemplu, dacă ne 
referim la asocierea dintre relaţiile Plan de Conturi şi Balanța care este de tip 1-1 
atunci putem avea conturi in relația Plan de Conturi care nu se regăsesc in Balanja. 
De exemplu, dacă presupunem că avem un client care nu mai desfăşoară timp de doi 
ani activitate cu noi iar soldurile aferente analiticului alocat lui sunt 0 putem să-l 
eliminăm din Balanța dar să-l păstrăm în Plan_de_Conturi. Sau un alt exemplu, 
Plan de Conturi conţine Planul de Conturi General în care se regăsesc şi conturi 
privind împrumuturile de la bănci iar firma nu face nici-un împrumut şi deci ele nu 
apar în Balanța. 


Li 


Reprezentarea acestei asocieri dintre Plan de Conturi şi Balanța este ilustrată in figura 


- "unu la mai mulți" (l-n): această asociere (one to many) se reprezintă grafic 
(Bachman) ca în figura 4.7. O asociere de tip l-n poate fi văzută şi ca 0-n. De 
exemplu, dacă ne referim la asocierea dintre relaţiile Balanța 5i Jurnal vom avea 
două asocieri de tip 1-n (figura 4.8) dată de faptul cà un cont din balanţă este debitat 
de una sau mai multe înregistrări din jurnal si creditat de una sau mai multe 


Un cont din balanța curentă, de exemplu al unui client care în luna respectivă nu 
realizează afaceri cu firma, poate să nu aibă rulaje asociate în jurnal. 

Schimbánd ordinea de plecare (de la S la R, figura 4.7 ) asocierea poate fi privită si 
interpretată ca aa _la unu" (many to one). 


1 [oeste creditat de 


leraditsazà, pe 


Notatia "1" din asocierile descrise poate desemna "0" ("nici-un") sau "I" ("exact un") 
element. 


- "mai mulți la mai mulţi” (a-m): această asociere (many to many) se reprezintă 
grafic (Bachman) ca în figura 4.9. 


Ín general, in tipurile de SGBD clasice (inclusiv in Access). această asociere nu poate fi 
reprezentată ca atare ci trebuia descompusă în asocieri de tip (1-n). Modelul relafional introduce 
posibilitatea descrierii directe asocierii (n-m), dar prin aplicarea normalizării se obține de regulă 
descompunerea în asocieri (l-n). Această descompunere se obţine introducând o relație 
ua, notată cu RxS, pentru a materializa asocierea conform modului ilustrat in figura 
4.10. 

La implementarea acestor tipuri de asocieri acestea pot fi: 

-= statice, caz în care se realizează prin mecanismul <cheie externă-cheie primară>; 

~ virtuale, caz în care se realizează la moment şi sunt în general precedate de un 

calcul. 

Revenind la descrierea in BNF a bazei de date relationale avem: 

- mulțime de — domenii>::=<denumire ——— domeniu><mulţime 

 domeniu»[«indicator de ordine] 

-  <denumire domeniu>::> <identificator> 

- mulţime valori domeniu>::=<valoare domeniu>|<valoare domeniu><mulțime 

valori domeni> 

-  <valoare domeniu>::=<valoare atomică> | «conditie apartenență la domeniu> 

- <indicator ordine>::= DA | NU. 


valori 


Fiecărui domeniu i se atribuie o denumire distinctă, «demumire domeniu> care 
reprezintă o generalizare a atributelor care îşi iau valori din domeniu. 

Denumirea atribuită domeniului <denumire domeniu> este un <identificator> format 
conform specificaţiilor limbajului de definire a datelor (sau componentei care realizează 
definirea datelor). În cazul în care această denumire nu este suficient de explicită este indicată 
descrierea sa în dicţionarul bazei de date (sub formă de comentarii, sub formă de linii de text în 
relații caracterizante din baza de date etc.). 

În cazul SGBD-urilor existente descrierea poate fi făcută ca un alias asociat coloanei la 
interogare (clauza AS) sau în modul Design modificând proprietatea Caption. 

Prin <mulțime valori domeniu> sunt desemnate toate valorile admisibile pentru acel 
domeniu (<valorile atomice» care verifică «condijia de apartenență la domeniui>). Aceste 
Valori care compun domeniul pot fi eventual ordonate («indicator de ordine>::= DA). Dacă se 
Sere ordonarea atunci această ordonare va fi efectuată conform specificaţiilor unei relaţii de 
Ordine între valori (<, >,<= etc.). 


la : 


Capitolul 4 


Prin condiţiile de apartenență la domeniu am desemnat cel puţin informaţiile care 
definesc natura si lungimea datelor (tipul, de exemplu, întreg, real etc.; lungimea, de exemplu, 
trei caractere, cinci întregi şi două zecimale etc.) la care se pot adăuga, eventual, alte elemente 
care precizează diverse restricţii : 

- <relaţie>::> «relafie denumită>/<relaţie anonimă> 

- <relație denumită>::> «relafie de bază>/<relaţie virtuală> 

- «relafie anonimă>::= <expresie relațională> 

- <relație virtuală>-:> «denumire de relaţie> <expresie relațională> 


<relaţie de bază>::= < denumire de relajie»[«mulfime atribute»] 

«cheie primară>(<chei alternative>)(<chei externe» ]«mulfime tupluri> 

- < denumire de relaţie>::= <identificator> 

= mulțime atribute>::= «atribut»|catribut* «mulfime atribute> 

-  <atribu>:2> < denumire atribut> < denumire domeniu>(<restricţii valori» 
- < denumire atribuf>::= <identificator> 

-  «cheie primară>::= <cheie alternativă> <restricții cheie primară> 

= «cheie alternativă>::= «candidat cheie>[<restricții cheie alternativă>] 


<mulțime denumiri atribur> 
ultime denumiri atribut> <restricţii cheie externă> 
<mulțime tupluri>::> <tupli>|<tuplu> «multime tupluri> 
<tuple>::> «multime valori atribut> 
<mulțime valori atribu>::> <valoare atribut» < denumire domeniu>[<restricţii 
valori atribut»] 

Relaţiile din baza de date pot avea un nume în cazul în care sunt <relaţii de bază> sau 
<relaţii virtuale» sau nu dacă sunt «relafii anonime>. E > H 

Diferența dintre o «relafie de bază> şi o «relafie virtuală> este dată de faptul că o ` 
«relafie de bazü» are extensia stocată în spațiul fizic asociat bazei de date relaționale (sub 
forma perceptibilă de tabel) pe când <relaţiile virtuale» se obțin ca urmare a aplicării unei 
<expresii relaţionale> pe relaţiile de bază. 

O <relaţie virtuală> (viziune) este obținută la momentul solicitării utilizatorului si este 
disponibilă, după obţinere, pentru aplicarea unor alte eventuale <expresii relafionale» de către 
alţi utilizatori. * 

O «relajie anonima» este un rezultat al aplicării unei <expresii relafionale» pe 
«relafüle de bază> şi/sau «relafiile virtuale» si este disponibilă, în general, pentru un singur 
utilizator, «relafüle de bază> şi <relaţiile virtuale» sunt definite în «schema de relaţi?> | 
(schema bazei de date relationale). i 

Relaţiile de bază pot fi grupate formal în următoarele tipuri: 

- nucleu; I 
- caracterizante; 1 


Relaţiile de tip nucleu sunt entităţile (tabelele) fundamentale ale microlumii de interes 
(universul lumii reale modelate). Ele reprezintă de fapt "despre ce este vorba în baza de date sau 
ce porțiune din realitate se modelează”. 

Relaţiile de asociere sunt relaţiile (tabelele) care permit materializarea asocierii dintre | 
două sau mái multe relaţii (entităţi). Fiecare participant la asociere poate fi o relație de tip 
nucleu, asociere sau caracterizantă. 1 

Relaţiile caracterizante sunt entităţi (tabele) al căror rol este de a califica, descrie sau | 
"caracteriza" alte entități (de orice tip). Existenţa entității caracterizante este dependentă de. 
existenţa entității pe care o caracterizează: "O entitate R este dependentă de entitatea S dacă 
este imposibil să existe o realizare a lui R dacă nu există o realizare corespondentà a lui S'^ 


r 


Baze de date relafionale 


Relațiile de asociere si cele caracterizante nu au o existență independentă ci presupun existența 
altor relații în baza de date. 

În general acest mod de grupare pe aceste trei tipuri este dependent de aplicație. Un 
tabel (o relație) poate fi privit(ä) de unii utilizatori ca asociere, de alții ca nucleu etc. De 
exemplu, într-o bază de date care cuprinde date despre angajați si locuri de muncă, entităţile 
care se referă la locul de muncă sunt tratate de către utilizatorul "compartimentul resurse 
umane” drept caractcrizante în timp ce utilizatorul "compartimentul de organizare a producţiei 
şi a muncii” le poate trata ca nucleu. 

În descrierea formală a relaţiei de bază au fost evidenţiate atât intensia cât şi extensia sa. 

Relaţiile urilitare sunt destinate stocării unor informaţii utilitare (cum ar fi descrierea 
restricțiilor de integritate, help-uri asociate sistemului, documentaţie etc), 

Pentru intensie au fost specificate clasele de atribute care o formează astfel: 

= <mulţime atribute>: sunt atribute considerate "ordinare" prin faptul că nu participă la 
formarea cheilor; 

- <cheie primară>: ca element unic de identificare şi desemnare a rândurilor 
(înregistrărilor, tuplurilor) reprezentând calea principală de acces la rând (tuplu); 

- <chei alternative>: pentru eventuala definire a unor căi de acces suplimentare la 
ad (tuplu) din considerente care privesc optimizarea timpilor de răspuns ai unor 
aplicaţii: 

- <chei externe»: ca elemente de importanță majoră în materializarea. asocierilor 
dintre rândurile (tuplurile) relațiilor. Aceste «chei externe» pot avea (şi au în 
general) asociate restricții care să asigure coerenţa logică a asocierilor. 

La utilizarea fiecărei <relaţii demumité? (definire, manipulare etc.) pentru «cheia 


primară> se vor utiliza următoarele reguli [DATE86]: 


= pentru fiecare atribut care participă la formarea cheii se va specifica faptul că nu sunt 
admise valori nule (NOT NULL); 

- se va crea un index care admite numai valori unice pe combinaţia tuturor atributelor 
care formează cheia primară (declaraţia de cheie primară este, în majoritatea 
imălementărilor modelului relational, echivalentă). Declaraţia index-ului va fi făcută 
fie declarând câmpurile drept cheie primară cu clauza CONSTRAINT 
demumire_restricție PRIMARY KEY sau cu comanda CREATE UNIQUE INDEX 
denumire index ON denumire_rabela (denumire_coloana [ASCIDESC) [, ...] 

- se va testa existența combinației de valori între intrările acestui index la inserarea 
oricărui tuplu (rând) în tabelă sau la modificarea valorii unei chei primare; 

- specificațiile pentru definirea cheii primare și a restricţiilor asociate vor fi trecute 
sub formă de comentariu în textul de definire sau într-o relație caracterizantă definită 
în acest scop. 


Similar, pentru fiecare cheie externă, se vor utiliza următoarele reguli: 

- pentru fiecare atribut care participă la formarea cheii se va specifica faptul că nu 
dune vélori mile dack si mamat dacă cheia coteta admite valori mule (NOT 

L); 

- ‘se analizează dacă este oportună şi imperioasă crearea unui index (în acest caz 
probabil că va admite valori duplicate) pe această cheie externă; 

~ se va utiliza mecanismul de autorizare al SGBD-ului pentru a interzice operaţiile on- 
line capabile să violeze restricţiile aplicate acestor chei externe. Aceste operaţii pot 
fi: ştergere în tabela referită; modificare a cheii primare a tabelei referite; adăugare 
în tabela care referă; modificare pe cheia externă în tabela care referă. 

- restricţiile cheii externe vor fi incluse în specificaţiile pentru programele de 
întreținere a bazei de date. Idealà este construirea unui singur program sau a unor 


as 


primitive care să manipuleze cheia externă şi care să fie apelate parametric de către 
Toii utilizatorii; 

- specificațiile pentru cheia externă şi restricţiile asociate vor fi conservate sub formă 
de comentarii în textul de definire sau într-o relaţie caracterizantă definită în acest 
scop. 


La aceste reguli vom adăuga următoarele: 

- deoarece o cheie externă materializează o asociere, asocierea reprezentând o 
proprietate calitativă a modelului datelor, este indicată scrierea unor programe 
(eventual parametrizate) de testare şi verificare a coerenjei logice care să 
semnalizeze orice violare a restricţiilor. Aceste programe vor fi rulate periodic in 
conformitate cu strategia impusă de administratorul bazei de date; 

- pentru cheile alternative pe care se presupune că vom crea indecşi se vor utiliza 
aceleaşi reguli ca la cheile extene. 


Fiecare <atribur> are o <denumire atribut» care nu trebuie, neapărat, să fie identică cu 
«denumire domeniu> a domeniului pe care este definit. Această <denumire atribut» reprezintă 
o interpretare semnatică a <domeniului> şi poate avea (conform acestei interpretări semnatice) 
asociată o restricţie prin care se specifică care valori din «mulfime valori domeniu> sunt 
considerate valide (deci şi acceptate) pentru interpretarea semnaticá dată. 

Extensia unei relaţii este o «mulfime tupluri>. Aceasta <mulțime tupluri» are o 
cardinalitate care variază în timp (se elimină/adaugă tupluri). 
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Proiectarea bazelor de date 
relationale 


Activitatea de proiectare a bazelor de date se încadrează in metodologia generală de 
realizare a sistemelor informatice. Plecând de la existența celor trei niveluri de organizare a 
datelor în baze de date, proiectarea structurii bazei de date va fi realizată in mod corespunzator 
celor trei niveluri - conceptual, logic şi fizic — parcurgând fazele descrise în figura 5.1. 

Proiectarea Conceptuală. Scopul acestei faze 
este acela al reprezentării cerințelor informal 
formulate ale aplicaţiei în termenii unei reprezentări 
complexe formale independentă de criteriile de 

tare ale unui SGBD anume. Rezultatul 
acestei faze este denumit schema conceptuală care 
reprezintă un model conceptual al datelor în care 
organizarea datelor este descrisă la un înalt nivel de 
abstractizare şi fără a ține seama de nici-un aspect de 
implementare. Proiectantul va trebui să reprezinte 
conţinutul informaţional al bazei de date fără a trata 
mijloacele prin care va fi implementată în SGBD-ul 
utilizat sau fără să se preocupe de eficiența 
programelor care vor utiliza aceste informaţii, 

Proiectarea Logică. Acestă fază constă în 
translatarea schemei conceptuale definită în faza 
precedentă într-un model de date acceptat de un 
SGBD disponibil. Rezultatul acestei faze este 
denumit schema logică a bazei de date care face 
referire la un model logic al datelor, În acest model 
reprezentarea datelor este efectuată independent de 
aspectele de reprezentare fizică. În acestă fază 
Fig. 5.1. Fazele proiectării bazei de | proiectantul va trebui să ţină cont de diverse criterii 

date de optimizare cerute de operaţiile necesare menţinerii 
şi regăsirii datelor şi să verfice calitatea schemei 
logice utilizate. Pentru modelul relafional tehnica formală utilizată pentru aceste optimizări si 
verificări calitative este reprezentată de normalizare. 
A Proiectarea Fizică. În acestă fază proiectul logic este completat cu detaliile 
implementării fizice (organizarea fişierelor, definirea portifiilor, caracteristicilor cerute spaţiilor 
fizice asociate componentelor, indecsi etc) specifice unui SGBD anume. Rezultatul acestei faze 
este reprezentat de schema fizică care este un model fizic al datelor. Acest model este dependent 
de SGBD-ul ales si tine cont de organizarea fizică a datelor în acest SGBD. 


Structura barai de date (scheme de relati, 
Testricil, indecşi sec) impreună cu 
decamentaţia sfermtà 
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înalt grad de generalitate este necesar ca acesta: 
a să emuleze perfect cadrul legal general care dictează condijile social economice de 


rezolvate ( să aibă o arhitectura de sistem deschis) ; 
să ale cttule de cornisa Hl operatori cre sl perelik Eoaea Ea Kari 


Condiţia necesară si suficientă 
respectarea cadrului metodologic si legal care guvemează funcţionarea domeniului de activitate 
emulat. Acest cadru legal este acela care asigură schimbul formal de informaţii între sistemul | 
emulat si celelalte sisteme cu care este în interacțiune. Respectarea completă a cadrului | 
metodologic si legal permite emularea pentru cel mai complex sistem care funcționează guvernat | 
de acestea. Subsistemele sau sistemele care nu acoperă întreaga sa complexitate vor avea, 
emularea funcţionării inclusă în sistemul complex ( generalizat ). 

Asigurarea arhitecturii deschise este cerută de faptul că sistemul proiectat trebuie să 
asigure emularea oricăror modificări ale cadrului metodologic sau legal. Aceste modificări surt 
evoluția sistemelor economico-sociale. 


eficienței. ră Ar dee hear ne rapit smog ere alea 
de informări. 

Arhitectura deschisă pentru operatorii de manipulare se referă tocmai la faptul de a putea | 
realiza pe baza datelor existente si alte prelucrări decât cele formale. De asemenea sistemul 
trebuie să admită şi eventuala modificare a cadrului sau static (structurile de date), farà însă a 


asigurarea 
depozite de dt aaa în generarea de ri, rcd ap cele cr e 
să o îndeplinească orice sistem informatic cu baze de date. 


5.1. Consideraţii privind proiectarea structurii 
conceptuale şi a structurii logice a bazelor de date 


Proiectarea bazelor de date relaționale 


În general, gruparea și stocarea datelor în colecţii (tabele) se face prin asocierea acestora 
obiectelor, sau activitțiilor desfăşurate în unitatea economico-socială de 
referință. Denumirea colecţiilor (tabelelor) va fi unică si dată astfel încât să sugereze cát 
mai bine obiectele, procesele sau activităţile de referință. Indicarea în paranteze a 
termenului “tabelă” a fost efectuată pentru a particulariza termenul de colecţie pentru 
modelul relational. Deoarece proiectarea modelului conceptual face apel la abstractizări 
o colecţie de date poate fi referită ca entitate, entitatea nefiind altceva decât “ceva” care 
are identitate proprie şi este distingibil de toate celelalte entităţi din jurul său. Încadrarea 
colecţiilor în categoria acestei abstractizări nu face altceva decât să specifice 
proprietăţile generale pe care trebuie să le moştenescă o colecție de date. Elementele 
entităţilor vor fi referite prin termenul realizare sau obiect, termen abstract care este 
referit concret în cadrul colecţiilor prin: înregistrare, rând, linie etc. 

- Definirea detaliată a colecțiilor de date. Este realizată de către echipa de proiectare, 
parte a grupului de administrare, a bazei de date. Punctul de plecare în proiectarea 
structurii logice îl reprezintă colecţiile de date, stabilite la nivel global in etapa de 
concepere a sistemului informatic, când s-a realizat totodată şi schiţarea unui prim 
model conceptual de ansamblu al datelor. Structura logică este rezultatul rafinării, 
validării, corectării si transpunerii în termenii unui model de date, acceptat de un SGBD, 
a acestui model de ansamblu al datelor. Se urmăreşte evidenţierea caracteristicilor 
(atributelor) obiectelor identificate și a legăturilor dintre aceste atribute si colecţiile de 
date. Pentru un obiect simplu caracteristicile vor fi cele care îl identifică si îl descriu, 
Pentru un obiect compus, caracteristicile vor fi cele de identificare a acestuia şi cele de 
descriere a obiectelor simple care sunt legate de cele compuse. De exemplu, într-o 
întreprindere care defăşoară activitate de producție, caracteristicile (atributele) asociate 
obiectelor MATERIALE ar putea fi, printre altele: 

* cod material (câmp indentificator, numeric întreg din 12 cifre); 

e denumire material (câmp alfanumeric din 30 caractere); 

* unitate de măsură (câmp alfanumeric din 6 caractere); 

pre de depozit (câmp numeric zecimal, format din 18 cifre cu două zecimale); 
* stoc normat (câmp numeric, format din 12 cifre cu trei zecimale), 

* stoc existent (câmp numeric, format din 12 cifre cu trei zecimale), 

* cont de materiale (câmp alfanumeric 22 caractere); 


interpretare — rol asociere M 


RS Lud 
denumire « re interp: A a 


(dela...) 


Această asociere a atributelor la o colecţie mu specifică care va trebui să. fie 
comportamentul colecției de aceea descrierea nu face decât să definească structura colecției care 
nu reprezintă altceva decât o descriere a proprietăților statice. Într-o descriere reală a unui 
sistem definirea unei colecţii de date mai trebuie să includă și specificaţii privind | 
comportamentul acestor elemente descriptive sau comportamentul întregului ansamblu al | 
acesteia. Descrierea comportamentului (reacția la stimuli) nu reprezintă altceva decât definirea | 
proprietăţilor dinamice ale colecției. 

- Determinarea asocierilor (legăturilor) dintre colecții (tabele). Se realizează pe baza 
legăturilor naturale care există între obiectele descrise cu ajutorul entităţilor 
identificate. Dependențele dintre obiecte pot fi ilustrate pe baza unui graf orientat în 
care fiecare nod reprezintă câte un tip de obiect iar arcele câte o dependență. O | 
asociere (figura 5.2) are loc de la... (S) o relație la.. (T) alta, privită astfel în funcţie de | 
semnificația sa pentru aplicaţia proiectată. O asociere între două entități are loc în 
ambele sensuri (poate fi traversată în ambele sensuri), fiecare sens putând avea propria 
sa interpretare semantică (interpretare). Asocierea poate fi de mai multe tipuri fiecare 
din acestea putând fi, la rândul lor, asocieri parțiale sau totale. Tipul asocierilor sí 
completitudinea acestora (parțială sau totală) se indică prin factorul de multiplicitate. 
Factorii de multiplicitate ai unei asocieri se specifică în text prin construcții de forma 
Xy, X-7y sau x-y, unde x indică capătul de la... iar y capătul la... O asociere 
definește o conexiune între entități cu unele structuri și semnificații comune si este 
calea de evideniiere a faptului că o informaţie nu aparține (nu este unică) numai unei 
entități, ci depinde de una sau mai multe entităţi, Fiecârei asocieri i se poate da o 


vd asociere 1-1 (n) 
Fig. 5.3. Reprezentarea grafică a asocierilor (UML) 


Ls] 
sp = pei 
ES dz asociere 1-0 (1) 
EAS 


E Determinarea tipului concret de legătură este efectuat pe baza unei analize a 
comportamentului tuplurilor colecțiilor între care apar. În cele ce urmează vom prezenta tipurile 
de legături prin studii de caz. Considerăm entităţile GESTIUNI şi MATERIALE între care 
există dependență. La fiecare asociere prezentată este exemplificată o instanță a asocierii prin 
valorile identificatorilor elementelor entităţilor respective specificaţi prin simboluri de forma Gi 
pentru gestiuni şi Mi pentru materiale. Simbolurile de forma GiMi specifică faptul că 
elementele entității respective sunt identificate de combinația identificator gestiune-identificator 
material. Cu aceste specificări asocierea dintre entitățile GESTIUNI şi MATERIALE poate 
ca: 
vw asociere de tip 1:1 atunci când in întreprindere într-o gestiune se poate afla un singur 
material (gestiune superspecializată, cum ar fi, de exemplu, un depozit de carburanţi 
care gestionează numai benzină fără plumb), iar un material poate aparţine de o singură 
gestiune, asociere reprezentată conform modului ilustrat în figura 5.4. 

- asociere de tip 1:n atunci când în întreprindere o gestiune cuprinde unul sau mai multe 
materiale (cum ar fi un depozit de carburanfi-lubrefianji al unei întreprinderi care 
conţine benzină 98, benzină fără plumb, motorină etc), iar un material poate aparține 
unei singure gestiuni, asociere reprezentată conform modului ilustrat în figura 5.5. 


Notim prin Gx identificatori de gestiuni și 
prin Mx identificatorii de materiale. În 


acest context asocierea apare astfel: 
ci—m 
c2—M 
63—MB 


Fig. 5.4. Asociere 1:1 Fig. 5.5. Asociere 1:n 


- asociere de tip m:n, când in întreprindere o gestiune cuprinde unul sau mai multe 
materiale, iar un material aparține uneia sau mai multor gestiuni, ilustrată grafic în 
figura 5.6. Asocierea de tip m:n se descompune, în general în asocieri de tip 1:n, mai 
uşor de analizat şi implementat la diferite SGBD-uri. Transformarea se realizează prin 
introducerea unei entități intermediare, denumită în cazul nostru 
GESTIUNI MATERIALE, conform modului ilustrat în figura 5.7. Entitatea de 


legătură introdusă 
s 
„Netâza prin Ga identificatoriü de. geniuni și prin Ma identificatarii 


Notăm prin Gx identificatorii de pr și | | demasteriao In aces contes asocierea poate apare asl 
prin Ms identificatorii de materiale. 
rin lem: M — ona 


aces context asocierea poate apare astfel: od 
GI zana 
G: 91M 
an 
scm 
, Ene 
ca 


G; 
Fig. 5.6. Asociere m:n Fig. 5.7. Transformarea asocierii m:n în 
asocieri 1:n 
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Proiectarea bazelor de date relaţionale 


Asocierile dintre entităţi pot fi: totale (când toate realizările entităților aflate în relaţie: 
apar în realizările relațiilor) şi parțiale (când unele din realizările entităților nu sunt legate prin 
relaţie). 

De exemplu, dacă entitatea GESTIUNI cuprinde informaţii despre toate gestiunile weil 
întreprinderi (deci inclusiv gestiunile de semifabricate sau produse finite, care nu sunt | 
“materiale”) si dorim să reprezentăm asocierea sa cu entitatea MATERIALE. În acest caz pot | 
exista gestiuni care nu deţin nici-un material pentru că, de exemplu, sunt gestiuni de produse | 
finite (în exemplificare referite cu G4) dar nu poate exista un material care să nu aparțină unei 
gestiuni. Acest gen de asociere poate fi ilustrat astfel: H 


În acest caz relaţia dintre GESTIUNI şi MATERIALE este o relaţie parțială care se 
indică prin 1:0 şi care se interpretează, in primul sens de la S la T, astfel: “entitatea S poate 
conține realizări care nu au corespondent în entitatea T" si în cel de-al doilea sens “în entitatea T 
nu pot exista elemente care nu au corespondent în S". 

Dacă s-ar fi avut în vedere numai gestiunile de materiale relaţia putea fi o relație totală: 


În stabilirea asocierilor dintre entităţi trebuie să se țină seama de posibilitatea existenţei 
de asocieri recursive (asocierea unei entităţi cu ea însăşi). 

Asocierile recursive pot fi, ca orice altă asociere de tipul 1:1, 1:n sau m:n, regulile de 
reprezentare fiind generale. 

Exemple de asocieri recursive (figura 5.8): 


- Asocierea de căsătorie. Se wilizează în cazul materializării asocierii de tip "Sot Sofie" 
care poate apare între realizările unei entităţi PERSOANE pentru a defini proprietatea 
stare civilă cu valoarea "Casitorit(8)": unei persoane căsătorite "Sof" îi corespunde o 
persoană "Sofie" şi unei persoane "Sojie" fi corespunde o persoană "Soj". Dacă entitatea 
PERSOANE conține numai realizări de tipul acestor cupluri atunci asocierea este de 
tipul 1:1. Dacă entitatea PERSOANE va confine informaţii despre toate persoanele 
indiferent dacă starea lor civilă este “Casătorit(4)” sau nu atunci asocierea este de tipul 
1:0 în sensul că nu trebuie să-i corespundă fiecărei persoane perechea sa dar persoanele 
există oricum. Reprezentarea grafică a acestei asocieri este prezentată în figura 5.8 a). 


Fig. 5.8. Exemple de asocieri recursive 


pasos] 
10) Pi) (0) FM 
a) b) 


- Asocierea de subordonare ierarhică a angajaților. Unui angajat (şef de ..) îi sunt 
subordonați mai mulți angajaţi iar un angajat este subordonat direct unui singur angajat 
(şeful său ierarhic), ceea ce corespunde unei asocieri de tipul 1:n, Deoarece în situații 
reale există cel puţin un angajat care nu are un șef direct, cum ar fi directorul general 
(sau preşedinte, administrator etc), ceea ce ne conduce să alegem o asociere de tip 1:0(n) 
în sensul că şeful suprem este angajat al întreprinderii dar nu este subordonat nimânui în 
timp ce ceilalți angajaţi sunt subordonați direct unui angajat, ceea ce defineşte o ierarhie. 
Reprezentarea grafică a acestei asocieri este prezentată în figura 5.8 b). 

- Asocierea de structurare a unui produs. Un produs este alcătuit din mai multe părți 
componente, părți care pot fi reprezentate de alte produse şi un produs este component 
al mai multor produse.. De exemplu, un calculator personal are în componență tastatură, 
monitor, mouse, etc şi reprezintă un produs care se vinde ca atare dar, la rândul lor, 
componentele enumerate monitor, tastatură, mouse Sunt la rândul lor produse care se 
vând ca atare. Dacă analizăm un calculator de tip main-frame şi acesta utilizează una sau 
mai multe tastaturi, unul sau mai multe monitoare etc. Reprezentarea acestei asocieri, 
care este de tipul m:n este redată în figura 5.8 c). 

determinarea asocierilor dintre entităţi trebuie să se ţină seama şi de existența aga 
numitor asocieri complexe (asocieri între mai mult de două entităţi). De exemplu, fie entităţile: 
FURNIZORI, MATERIALE, DEPOZITE şi asocierile binare corespunzătoare, conform 
modului ilustrat in figura 5.9 a). Aceste asocieri permit să se determine furnizorul unui material, 
ce material intră într-un depozit şi ce furnizor aprovizionează un depozit. Însă nu se poate 
determina ce furnizor aprovizionează cu un produs un anume depozit. Aceste informaţii se pot 
obține numai prin introducerea unei asocieri, ca entitate de legătură, care să lege cele trei 
entităţi, conform modului ilustrat în figura 5.9 b). Orice asociere complexă poate fi descompusă 
in asocieri binare în același mod în care o asociere m:n este descompusă în asocieri 1:n. 

Odată stabilită o asociere între anumite entităţi, indiferent de tipul acestora, deosebit de 
importantă este definirea corectă a semnificației acesteia. Înțelegerea corectă a semanticii 
asocierii este esenţială în utilizarea ei ulterioară, în interpretarea informațiilor regăsite pe baza 
acesteia, în memorarea corectă a diferitelor informaţii. Erorile de interpretare se produc datorită 
existenţei, în cele mai multe cazuri, a mai multor asocieri între entităţi. 

De exemplu, între entităţile: PRODUSE şi SECTII pot exista asocieri de consum a 
produselor în cadrul secţiilor sau asocieri de producere (realizare) a produselor în secţii. De 
aceea, când se stabileşte asocierea trebuie bine fixată semnificaţia, semantica atribuită asocierii. 
Sau, între entităţile: SECTII şi ANGAJAȚI se pot stabili asocieri de încadrare a unei persoane 
ip activitatea unei secții sau asocieri de conducere a unei seci de către o anumită personà (șeful 

secţie). 

Exemple de asocieri complexe: În cadrul subsistemului aprovizionării pot fi identificate 


următoarele tipuri de obiecte simple: MATERIALE, PRODUSE, CONTRACTE, FURNIZORI, 
GESTIUNI, SECTII, ANGAJATI etc. Se vor analiza în continuare relaţiile stabilite între aceste 


obiecte simple apoi se va construi diagrama dependenjelor dintre entităţile asociate obiectelor 
identificate. 


- Asocierea dintre MATERIALE şi FURNIZORI. Un material poate fi furnizat de unul | 
sau mai mulţi furnizori, iar un furnizor poate furniza unul sau mai multe materiale, ceea | 
ce înseamnă că o astfel de situație generează o asociere de tip "multi-la-multi" (figura 10 | 4 l 

a). Pentru transpunerea în practică a unei astfel de asocieri se recurge la transformarea 

1 


3 


acesteia de la tipul de legătură m:n la o legătură de tipul 1:n prin introducerea unei 
entităţi intermediare pe care o vom denumi MATERIALE, FURNIZORI, ceea ce ar 
insemna cà asocierea iniţială va suporta modificări sub aspectul descrierii ei și va apare | 
grafic ca în figura 5.10 b). Principial informaţia pe care trebuie să o reprezinte entitatea | 


de asociere ar fi reprezentată de identificatorul realizărilor entității materiale si 
identificatorul entității furnizori. Datele stocate vor conţine perechi de valori ale acestor | 
identificatori. 


a) 


b) 
Fig. 5.11. Asocierea MATERIALE-CONTRACTE 


a) b) 
Fig. 5.10. Asocierea MATERIALE-FURNIZORI 


a) 


- Asocierea dintre MATERIALE si CONTRACTE. Un material poate fi contractat prin 
mai multe contracte iar un contract poate cuprinde mai multe materiale, ceea ce 
înseamnă că şi de această dată se impune o entitate intermediară, conform modului 
ilustrat în figura 5.11 a) si b). 

- Asocierea dintre MATERIALE si GESTIUNI. Un material poate aparține uneia sau mai 
multor gestiuni si o gestiune cuprinde unul sau mai multe materiale. Reprezentarea 
asocierii m:n este prezentată în figura 5.12 a) iar transformarea sa în asocieri de tipul 1:n 
în figura 5.12 b). 

- Asocierea dintre MATERIALE si TEHNOLOGII. Un material este utilizat de una sau 
mai multe tehnologii de fabricaţie iar o tehnologie de fabricaţie poate utiliza mai multe 
materiale. Legătura dintre aceste tipuri simple de obiecte este asigurată de entitatea 
intermediară MATERIALE_TEHNOLOGII. Între aceste obiecte simple există o 
corespondență tot de tipul mn, care trebuie transformată într-o relație de tipul 1:n, 
conform modului ilustrat în figura 5.13 a) şi b). În acest caz entitatea de legătură 


r 
| 
! 
| 
1 


b) 
MATERIALE TEHNOLOGII poate conţine, pe lângă identificatorii entităților aj a a ^ OLOGI 
implicate si atribute proprii cum ar fi, de exemplu, consumul specific, preţul operației ls Fig. 5.13. Asocierea MATERIALE-TEH 
etc. 
Prin analogie mai pot fi identificate şi alte obiecte şi relaţii referitoare la subsistemul de 
aprovizionare, 


einni 
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5.2. Normalizarea tabelelor bazei de date 


52.1. Conceptul de normalizare 


Ținând seama de faptul că definirea si stocarea datelor sub forma colecţiilor suferă E 

timp o serie de schimbări, în fața proiectanjilor se ridică numeroase probleme de genul: 
pot fi prevăzute logic şi ee problemele de actualizare a datelor şi ținute sub x 
toate modificările ce intervin ? 
cum s-ar putea imagina o structură iniţială de colecţii de date care să sufere cât mai. 
puţine modificări în viitor şi să fie, totuşi, cát mai flexibilă ? 
Cum s-ar putea proiecta acea structură iniţial de colecții da date care să producă în viitor | 
cele mai puţine dificultăţi privind actualizarea datelor sau modificarea structurii datelor? 1| 
cum poate fi asigurată o independență sporită a programelor de aplicaţie faţă de | 
structura datelor (imunitatea programelor de aplicație față de structura datelor) ? f 
Bazele de date relaționale fin foarte mult seama de aspectul dinamic al structurii si stării 
datelor şi caută să dea soluția unei astfel de probleme. Tocmai întreaga filozofie a bazelor 
date relaţionale porneşte de la posibilitatea schimbării frecvente a structurii si actualizări 
îşi regăsesc aplicabilitate deplină acolo unde există o dinamică mare a modificărilor 
timp si spaţiu. 

În activitatea de proiectare a structurii bazelor de date relaționale se utilizează pe 
rormalizării relaţiilor, care caută să dea răspuns întrebărilor formulate anterior. 

Pentru infelegerera tehnicii normalizárii relaţiilor finem să precizăm că, bazele $ m 
relaţionale se sprijină pe teoria matematică a miltimilor. Conform acestei teorii, reprezentarea“ 
oricărei structuri de date poate fi redusă, acceptând o anumită redundanţă, la un tabel sau mai 
muke tabele bidimensionale ce caracterizează relaţii între mulțimi. Tabelele trebuie astfel || 

construite încât să nu piardă informații de legătură. Prin procesul de normalizare se precizează . 
szuetura logică a unui ansamblu de date, în specificul realților lor, sub formă de tabele) 
bidimensionale, înlăturând astfel complexitatea şi rigiditatea structurii bazei de date. 

Teoria normalizării este construită în jurul conceptului de forme normale (FN). Au fost, 
definite numeroase forme normale. Iniţial Codd a definit trei forme normale: FN1, FN2, FN3. 
Forma normală trei (FN3), definită original de Codd, suferă de anumite inad . O definiţii 
revăzută (mai puternică) a formei normale trei a fost dată de Boyce şi Codd în [CODD 74] 
este referità în literatura de specialitate sub prescurtarea BCNF (Boyce Codd Normal Form). 
Fagin a definit [FAGIN 77] o nouă formă "a patra” (FN4) si apoi [FAGIN 79] încă o formă | 
normală, numită "forma normală proiecfie-jonctiune" (PJ/NF), cunoscută si ca forma normală, 
cinci (FN5). Despre o relaţie (un tabel) se spune că este într-o formă normală dacă | 
satisface anumite restricţii. Motivarea acestor restricționări este că relaţiile în FN2 sunt de | 
referat celor în FNI, într-un sens ce va fi discutat ulterior, că la rândul lor rândul bes 
ENS sunt preferabile celor în FN2 ș.a.m.d. 

Figura 5.14. sugerează faptul că toate relațiile normalizate sunt în forma normală unu 
(ENI), o parte din relaţiile FN1 sunt şi în forma normală doi (FN2), o parte din relaţiile (FN2) | 
smt şi în forma normală trei (FN3), o parte din relaţiile FN3 sunt si în forma normală | 
Boyce-Codd (BCNF), o parte din relaţiile BCNF sunt și în forma normală patru (ENA) şi inj 
Seit o parte din relațiile ENA sunt si în forma normală cinci (FNS). Numărul formelor! 
normale definite în prezent este de 9 dar majoritatea SGBD actuale lucrează corect cu baze de 
cate în forma normală FN3 (BCNF, este preferabil). 


smut i 


Proiectarea bazelor de date relaţionale 


Fig. 5.14. Normalizare — Forme Normale 


Prin parcurgerea acestor forme normale se ajunge in mod succesiv să se amelioreze 
structura bazei de date, inlàturándu-se treptat o serie de neajunsuri şi imprimând facilităţi sporite 
în privinţa încărcării, actualizării şi exploatării bazei de date. De remarcat faptul că, nu in toate 
cazurile se impune parcurgerea tuturor formelor normale, însă în mod obligatoriu prima formă 
normală este implicată. 


5.2.2. Obiectivul si necesitatea normalizării relaţiilor 


E. F. Codd a observat, la modelul de date relaţional, că anumite relaţii pot genera o serie 
de situaţii nedorite, asa numitele "anomalii de actualizare". Pentru a ilustra principiile de bază 
ale acestora vom considera exemplul din figura 5.15 în care este prezentat un tabel cu informaţii 
utile privind persoanele implicate în activitatea de cercetare si fondurile implicate la derularea 
unor proiecte. Un angajat poate participa la mai multe proiecte de cercetare iar un proiect de 
ari soti ine na n 


Fig. 5.15. O instanţă a relației CERCETARE 


Cheia primară a acestui abel este formati din atributele Angajat și Proiect, Această 


relație respectă, în afara proprietăților generale ale unui tabel în modelul relational, următoarele 


s salariul fiecărui angajat este unic şi depinde numai de angajat (este independent de 
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proiectul la care lucrează); 
- bugetul alocat fiecărui proiect depinde numai de proiect şi este independent de angajaţii 
care lucrează la el. 


Vom analiza această relație din punctul de vedere al conținutului său şi al operațiilor pe 
ete dorina a6 IS Sai a dei NS 

valoarea pentru salariu a fiecărui angajat este repetată în toate rândurile care se referă la 

el; similar valoarea bugetului alocat unui proiect este repetată In toate rândurile legate de 


reduce) bugetul unui proiect va trebui să modificăm acea valoare în toate liniile în care 
apare. Din acestă actualizare a informaţiei în mai multe tupluri pot rezulta tupluri, din 
diverse motive, în care informaţia este actualizată și tupluri în care nu este. Această 
anomalie este referită ca anomalia de actualizare; 

- dacă un proiect se termină atunci datele sale trebuiesc şterse din tabel. Prin ştergerea 
liniilor referitoare la proiect putem să pierdem informaţiile privind angajaţii si salariul 
lor, de exemplu, prin stergerea proiectului MEC s-ar pierde datele despre angajatul 
BODEA care lucrează numai la acest proiect. Acest lucru apare deoarece Proiect este 
parte a cheii primare şi în acest context nu putem să păstrăm rânduri care nu au valori 
pentru atributele cheie. Această anomalie este referită ca anomalia de ștergere; 

- dacă dorim să angajăm o nouă persoană nu vom pute introduce datele sale de 
identificare si salariale până când nu-l repartizăm la cel puţin un proiect sau nu putem să 
înregistrăm un proiect nou până când nu îi repartizăm cel puţin un angajat. Această 
anomalie semnalată este referită ca anomalie de ştergere. 


Anomaliile semnalate apar datorită faptului că: 

- n activităţile reale este necesar să repetăm datele ceca ce face ca o aceeaşi dată să apară 
în diferite tupluri; 

- Anomalia de ştergere rezultă din faptul că stergánd un tuplu al unei relații, odată cu 
eliminarea informaţiilor ce trebuiau şterse se pierd și informaţiile utile, existente în 
tuplul respectiv. Această anomalie nu apare neapărat atunci când ştergem tuplul în 
întregime ci mai degrabă atunci când dorim să ştergem numai un câmp iar informaţia în 

- Anomalia de adăugare (inserare) rezultă din faptul că nu pot fi incluse noi informaţii, 
necesare, într-o relaţie dacă nu se cunosc și alte informaţii cerute pentru adăugarea unui 
nou tuplu la acea relație, în principal valorile pentru atributele din cheie; 

- Daci o anumită informaţie este repetată redundant actualizarea sa trebuie să fie repetată 
pentru fiecare apariție a sa. Astăzi SGBD-urile comercializate pun la dispoziție, prin 
IC ca, ni căt pna ser a cai eg ne a co 
rezolvă problema dar numai din punctul de vedere al programatorului si nu a sistemului 
bazei de date. Această anomalie de modificare rezultă din faptul că este dificil de 
modificat o valoare a unui atribut atunci când ea apare în mai mult decât într-un tuplu al 
relaţiei deoarece la actualizare este necesară accesarea fizică a mai multor tupluri iar 
caderile pot provoca timpi de refacere considerabili. 

Anomaliile de actualizare nu apar numai la modelul relational ci si la celelalte modele 
de date cum ar fi ierarhic, rețea şi fişierele clasice. Pentru modelele ierarhic și reţea nu există o 
teorie a rezolvării anomaliilor de actualizare. Rezolvarea lor este lăsată în seama utilizatorilor 
fără să fie dată cel puţin o indicație în acest sens. Din această cauză apar în mod frecvent 
anomalii de actualizare la bazele de date de tip ierarhic sau reţea deja încărcate cu date reale, 
când este foarte costisitor şi foarte dificil să schimbi structura bazei de date. Ori, problema 


IDE aior de actatizaro trebuie rezolvată fo etapa do proiectare x bazei de date și m düpk os 


baza de date a fost încărcată cu date reale şi au fost scrise aplicaţii pentru ea. 

=i În acest context, teoria normalizării relaţiilor isi propune, înlăturarea acestor anomalii 

încă din faza de proiectare a structurii bazei de date. Deci, se poate arăta că prin normalizarea 

relaţiilor se urmăresc în mod deosebit performante de ordin logic si în mod implicit vor rezulta 
şi performanțe de ordin fizic, cum ar fi ocuparea raţională a suportului de memorie externă sau 

Poe dd de ul seu. 


5.2.3. Dependenţe funcţionale 


Conceptul de funcţională (DF — functional dependency) în domeniul 
proiectării structurii bazelor de date, a fost introdus de E.F. Codd în scopul de a caracteriza 
relaţiile care pot fi descompuse fără pierderi de informaţii în două sau mai multe relaţii. O 

funcţională este o formă particulară de restricţie de integritate a modelului relational 
care descrie asocierile funcţionale dintre atributele unei relaţii. Pentru a explica acest concept de 
dependenţă funcţională vom analiza relaţia din figura 4.15. În această tabelă bugetul alocat unui 
proiect este unic si ori de câte ori apare acelaşi proiect într-un tuplu valoarea bugetului rămâne 
aceeaşi. Putem afirama faptul că valoarea atributului Buget este dependentă funcțional de 
valoarea atributului Proiect, adică formal putem afirma că există o funcţie care asociază fiecărei 
valori pentru atributul Proiect a singură valoare pentru atributul Buget, 


Definiţie: Fie relaţia r cu schema de relație RX) cu X = (AyAs, Au) şi Y si Z 
submulțimi nevide de atribute din (A145... Ax). Se spune că avem o dependenţă funcțională pe 
r între Y şi Z (notat cu Y->Z) dacă pentru toate toate tuplurile pereche tu, Ișer având aceeași 
valoare a atributelor. Y tuplurile t;, t; au aceeaşi valoare pentru atributele Z, adică: t,[Y] = 
aY] => 17) = Z]. 


Cu alte cuvinte, fiind dată o schemă de relație R(X) si (X) o instanţă a sa, atributul 
(sau mulţimea de atribute) ZeX este dependent funcţional de atributul Y e X dacă si numai 
dacă două sau mai multe tupluri din r cu aceeași valoare y; în coloana Y implică existența 
aceleiaşi valori z; în coloana Z a acelor tupluri. 

Mai simplificat, fiind dată o schemă de relaţie R, atributul YeR este dependent 
funcțional de atributul X cR, dacă si numai dacă pentru o valoare atribuită lui X, lui Y li va 
corespunde întotdeauna o singură valoare. Pe orice relație există anumite dependențe 
SR EU T a AD pate apt Aa 


Cel mai simplu exemplu de dependenţă funcţională îl constituie corespondența 

biunivocă dintre mulțimea codurilor de materiale şi mulțimea denumirilor de materiale. Unui 
anumit cod de material fi va corespunde întotdeauna o anumită denumire de material. 
Pentru a sugera dependeța funcțională dintre un atribut sau o mulțime de atribute Y faţă de un 
atribut sau o mulţime de atribute X se recurge la notația: X—>Y (adică Y depinde funcţional de 
X), unde X formează partea stângă, iar Y partea dreaptă a dependenței funcţionale. Pe exemplul 
din figura 5.15 avem dependentele funcționale: Proiect-»Buget, Angajat Salariu. 

Deoarece atributele Angajat şi Proiect reprezintă cheia şi conform definiției acesteia nu 
Putem avea două valori identice vom avea dependența Angajat Proiect->Salariu Buget Funcție. 
Pa e ges Prom Da de D LONGE PAS Ma Gn o 
tilizată în expunere. 
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Noţiunea de dependență funcțională generalizează noțiunea de supercheie: mulțimea de 
atribute K este o supercheie a unei relaţii R(X) dacă K->X. Prin acestă generalizare a noţiunii 
de supercheie dependentele funcţionale ne permit să definim restricţii de integritate care nu pot 
iri endl esae A S Pay | 

Dependențele funcționale pot fi utilizate moduri: 

& po a ee a a cd o dM nice Ia 
relaţie r este legală pe setul de dependențe funcționale F vom spune că relația r satisface ^| 

E 


2 Pentru a specifica restricțiile pe setul relațiilor legale. În acest mod ne permite să um fa ` 
calcul numai acele relaţii care satisfac setul dat de dependențr funcţionale. 


Plecând de la relaţia produsului cartezian dintre mulțimile de atribute A şi B aparținând | 
domeniilor DOM.A si respectiv DOM.B, forma generalizată a dependenței funcţionale apare 
astfel: A A2...Aa->Bi B2...Ba " 1 

-o relație în care apar chei concatenante (chei formate din combinaţia mai multor 
atribute), între atributele cheie şi atributele ce nu fac parte din cheie (noncheie) pot exista 
dependențe funcţionale complete si parţiale. i 


Exemplu: Fie relaţia r, definită pe schema R(A,B,C,D): 


Pe acestă relaţie se observă că: 

- există dependența A->C deoarece avem două tupluri care au în coloana A valoarea 
iar aceste tupluri au aceeaşi valoare cl în coloana C; similar celor două tupluri 
valaorea a2 în A le corespunde aceeași valoare c2 în C gi nu mai avem alte perechi | 
distincte de tupluri cu aceeași valoare pentru A; 1 

- dependența funcțională C->A nu este satisfăcută deoarece dacă luăm perechea de tupluri | 
t şi ts care au cecași valoare c2 în coloana C acestea nu au aceeași valoare în coloana A, ^ 
adică avem tuplurile t4 şi ts pentru care t[C]=ts[C] dar t[A]&ts[A]; 3 

- existi si alte dependențe satisfăcute de relația r cum ar fi: AB->D (observați 
combinaţiile valorilor din coloanele AB), A->A etc. 


Exemplu: Fie relaţia R cu schema de relaţie R(A, B, C, D, E, F, G) şi cheia relaţiei 
îi d A A M e ea SR At SI 
diagrama dependenjelor funcționale reprezentată in figura 5. igura 5.16 se sugerează că | 
atributele C şi D depind funcțional de atributul A, care face parte din cheie, jar atributele E, F, G 
depind funcțional atât de atributul A cât si de B. În primul caz se spune că avem de a face cu o. 

$ 
4 


privite ca dependente parțial de A si B şi dependente complet de A. 


Fig. 5.16. Exemplu de diagramă a dependenfelor 
funcționale 


În contextul acestor două exemple se poate spune că un atribut sau o mulțime de atribute 
B din cadrul unei relaţii este dependeni(ă) funcţional complet de o mulțime de atribute A ale 
aceleiaşi relaţii dacă B este in mod funcţional dependent(à) de întrega mulțime A si nu numai de 
o submulțime a lui A. 

Remarcám faptul că recunoașterea dependenjelor funcționale este o parte esenţială a 
înțelegerii semnificației sau semanticii datelor. În general, dacă avem un set de dependențe 
funcţionale, aceste dependențe funcţionale pot implica alte dependențe funcționale. De exemplu 
presupunem că avem o relație cu schema R(A,B,C,D,E,F) si un set de dependențe pe acesta: 
[A9B, AC, CD>E, CD->F, BE), pe care le vom reprezenta grafic ca în figura 5.17 
(liniile continue). În general nu este suficient, pentru o relaţie dată, să considerăm numai 
dependentele funcţionale date ci toate dependenjele funcționale care au loc. 

Dacă F este un set dat de dependențe funcționale se poate demonstra că există şi alte 
dependențe funcţionale, despre care vom spune că sunt logic implicate de F. Pe exemplul 
nostru, dependența A>E este logic implicată deoarece A->B si B-E, adică B este dependent 
de A iar E este dependent de B ceca ce conduce logic la E depinde de A si similar se poate 
deduce dependenţa AF (figura 5.17 liniile punctate). 

Vom nota cu F’ închiderea lui F, cu F^ reprezentată de setul tuturor dependentelor 
funcţionale logic implicate de F. Dacă F este dat atunci aplicând repetat o serie de reguli 

ite axiome sau regului de inferență) putem calcula închiderea sa. Dacă F este mare 
atunci calculul lui F^ poate să fie extrem de laborios. Fie W, X, Y şi Z mulţimi de atribuite 
aparținând unei relaţii R. 

Dependenjele funcţionale dintre atributele unei relaţii se supun următoarelor reguli de 
bază (denumite axiome sau reguli de inferență): 

- Reflexivitate. Dacă X este o mulţime de atribute şi Y este o submulțime a sa, adică 

YSX, atunci XO Y; 

- Cregtere. Dacă XY, atunci XZ->Y2. Această regulă semnifică faptul că dacă X 
determină pe Y atunci aceste două mulțimi de atribute pot fi îmbogăţite printr-o a treia 


mulţime Z; 
-~ Tranzitivitate. Dacă XY şi YZ, atunci X->Z. : 
* Aceste trei reguli ce funcţională sunt cunoscute în literatura de 


" guvernează dependența 
specialitate sub denumirea de <<Axiomele lui Armstrong>> şi- ele nu generează nici-o 
dependenţă funcțională incorectă. 


— Dependente funcţionale date 
mS Dependente funcţionale logic implicate 
[x]. Atribut sau combinaţie de atribute 


Fig. 5.17. Dependenfe funcționale logic implicate 


Din aceste axiome mai pot fi deduse alte cáteva reguli si anume: 
- Reuniune. Dacă XY si X-Z, atunci X2 YZ; 
-  Pseudotranzitivitate. Dacă XY si YW->Z, atunci XW—Z; 
- Descompunere. Dacă X—>YZ, atunci XY si X-Z. 

Dacă aplicăm aceste reguli setului de dependențe funcționale P=(A->B, AC, 

CDE, CDF, BE) vom obține, printre altele, următoarele dependențe din F”: 
- AOE din A>B si BE prin tranzitivitate (regula 3); 
- CDEF din CD>E si CDF prin reuniune (regula 4); 
- ADF din AC prin creştere (regula 2) avem AD->CD iar CD—F prin definiţie şi 
aplicând tranzitivitatea obținem ADF; 
- ADOE similar precedentei; etc, 

Utilizând aceste reguli apare posibilitatea definirii noţiunii de dependență funcţională 
elementară de forma XA, unde A este un atribut unic neinclus în X (AX) şi nu există un alt 
atribut XX astfel încât XA. 

Plecând de la o mulțime de dependențe funcţionale elementare, se pot compune prin 
tranzitivitate alte dependențe funcţionale elementare, Se ajunge astfel la noţiunea de dependență 
tranzitivă a unei mulţimi de dependențe funcţionale elementare, mulţime de dependențe ce va fi 
utilizată la definirea formei normale 3 (FN3). 


5.2.4. Formele normale unu, doi si trei 


Primele trei forme normale au ca obiectiv definirea unei scheme conceptuale a bazei de 
date plecând de la entităţile si asocierile iniţiale ale modelului real. 

În general se pleacă de la o relație universală (entitate unică) sau chiar de la mai multe 
relaţii şi se urmăreşte descompunerea fără pierderi de informaţii a relaţiilor in subrelaţii care nu 
suferă de anomalii de ordin logic şi fizic. Descompunerea relaţiilor se va face pe baza analizei 
dependenfelor funcționale dintre atributele cheie si atributele care nu fac parte din cheie. 

Întregul proces de normalizare se desfăşoară în etape succesive (forme normale) şi se 
caracterizează prin rafinament, iar în final va duce la izolarea entităţilor şi asocierilor lumii reale 
în scopul facilitării manipulării relaţiilor. Descompunerea relaţiilor în subrelafii presupune o 
bună înțelegere a proprietăţilor semantice a datelor. O proastă înţelegere a lumii reale şi 2 
semnificației datelor ce o descriu poate conduce la relaţii problematice. 
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Semnificația Normalizării 


Fig. 5.18. Semnificaţia procesului de normalizare 
Figura 5.18 sugerează, în principiu, procesul de normalizare plecând de la o relaţie 
universală printr-un proces de descompunere. Dacă U este o schemă de relaţii (universală sau 
nu) atunci mulţimea schemelor de relaţii (R4,Rz....Rn) este o descompunere a lui U dacă orice 


atribut din U apare cel puţin într-o relaţie Ru unde i 


a 

n, adică U = | JR, . Fie u o relație cu 
Ll 

schema U si fie n, 2 [T y, (2 671,2,..,n, adică (ria... 7s) este baza de date care rezultă 


" 
prin descompunerea lui U in (R;, Rs... Rn}. Întotdeuna vom avea t € x 7. 
i a 


Pentru exemplificare ne vom referi la definirea schemei conceptuale a unei baze de 
date simplificate privind activitatea de aprovizionare cu materii prime şi materiale. 

În acest scop vom defini două relaţii inițiale cu denumirile CONTRACTE şi respectiv 
MATERIALE ale unei baze de date pentru activitatea de Aprovizionare. Totodată, vom pleca 
de la premisa că un contract se încheie cu un anumit furnizor, că printr-un contract pot fi 
cumpărate unul sau mai multe materiale, că un material poate fi livrat într-o singură tranșă sau 
în mai multe, egalonate pe termene prestabilite, ceca ce se sugerează în figura 5.19. 


C) e elio anm furnizor; 
- Cı contractul i încheiat cu un anumit 
(s) © © = Mp materialele contractate printr-un anumit 
- Desi de materiale; 
G A O 
(n) SE SE 
Fig. 5.19. Structura datelor în relația 
CONTRACTE 
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Structura ini EDD coU (figura 5.20): 


STOC EX. 


is 
Fig. 5.20. Relaţii inițiale 


unde semnificaţia prescurtărilor este: 

CODM-codul materialului; DENM-denumire material; UM-unitatea de măsură; 
PRET LIVR-prej livrare; STOC_SIG-stoc de siguranţă; STOC_EX-stoc existent; 
NRC-aumăr contact; DATAC-data încheierii contractului; VALC-valoarea 
contractului; CODF-codul fumizorului; DENF-denumirea furnizorului; CODL-Cod 
Localitate; DENL-Demumire localitate; PREFTX-prefixul telefonic al locali 
CONTB-cont la bancă; CANTPL — cantitatea planificată a fi livrată în cadrul unei h 
CANTLIVR — cantitatea livrată în cadrul unei luni; CANTREF - cantitatea refuzată în 
cadrul unei luni. 


În cadrul relațiilor au fost subliniate atributele care fac parte din cheie ale fiecărei 
relaţii. 


Aplicând tehnica normalizării, să urmărim în ce măsură relaţiile în forma iniji 
prezintă anumite anomalii de ordin logic şi fizic şi cum anume pot fi înlăturate aceste anomalii, $ 
astfel încât, în final, să se ajungă la o structură performantă sub aspectul facilităților de -| 
încărcare, adăugare, modificare si regăsire a datelor. 

Primul pas în cadrul procesului de normalizare constă în a analiza relaţiile prin prisma ` 
cerințelor şi restricţiilor formei normale unu (FN1). 

Definiţie: O relaţie R se găseşte în FNI dacă şi numai dacă dert: ei conțin numai į 
valori elementare (atomice). 


Conform definiției date, relația MATERIALE se găseşte în FNI, 


fociis CODD, denumirea localităţii (DENLOC) ete. 1 
Totodată, se observă cà este posibil ca printr-un contract să se contracteze mai multe f 
materiale, iar fiecare material să fie egalonat în tranșe corespunzătoare fiecărei luni a anului. 
Acest aspect face ca în cadrul relaţiei CONTRACTE anumite atribute, cuprinse în paranteze 
unghiulare şi regrupate sub denumirile de MATERIALE si EȘALONĂRI, să genereze valori | 
repetitive. Deci, există tupluri ale căror valori nu sunt atomice (valorile încadrate în | 
dreptunghiuri punctate). $ 
Prezența în cadrul relațiilor a unor câmpuri compuse (MATERIALE şi ESALONARI) 
generatoare de atribute cu valori repetitive vor putea produce o serie de anomalii, astfel: 
- la modificarea datelor, poate apare necesitatea corectiei aceloraşi date în mai multe 
tupluri; 
- a pă rii em m nm de earnet ee 


- a i ura, ca de ci inte cual de dte 


Proiectarea bazelor de date relaționale 


Referitor la atributul ADRESA, care generează valori compuse şi acesta poate 
determina neajunsuri atât sub aspectul încărcării si actualizări aceloraşi date de mai multe ori, 
các gi sub aspectul descrierii şi modului de reprezentare pe suportul de memorie externă. 

Pentru a normaliza relaţia CONTRACTE vom descrie, pe de o parte, atributul ADRESA 
sub forma cod-localitate (CODL) şi denumire-localitate (DENLOC), iar pe de altă parte, vom 
avea în atenţie că orice relaţie care conţine câmpuri compuse se poate "sparge" în atâtea relaţii 
suplimentare câte câmpuri generatoare de repetiţii există. Pentru aceasta, fiecare apariţie de 
câmp compus care generează repetiţia se asociază în relația cu cheia primară. 

În mod asemănător, orice structură de date de tip arborescent sau reţea se poate descrie 
ca o succesiune de relaţii după următorul algoritm de normalizare: 

- scia prima relaţie de la rădăcina arborelui si cheia sa primară se va insera înaintea cheii 
primare a relaţiilor subordonate; 

- se suprimă în relația rădăcină câmpurile agregate ce acceptă o descompunere până la 
nivel elementar; 

- se repetă în aceiaşi manieră operaţia cu fiecare subarbore al structurii. 

Conform acestor precizări relația CONTRACTE va fi descompusă în următoarele 
subrelafii: 


[CONTRACTE = CNRC :CODF, DENF; CODI; E ipis SEBLAFON 'REFIX. CONTB, 
| DATAC, VALC>. 
MATERIALE ( „CONTRACTE = P d 

| |ESALONĂRLI LIVRÁRI * <NRC. CODM, LUNA; CANTPL, CANTLIVR, CANTREFS 
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Fi 


„5.21 Relaţii in ENI deduse din relaţia CONTRACTE din fi 


Prin această descompunere a relației inițiale CONTRACTE s-a ajuns la trei subrelaţii cu 
chei concatenate (atributele subliniate), ce se găsesc în ENI. 

De remarca! faptul că în urma acestor descompuneri nu s-a pierdut nici o informaţie de 
legătură, relația iniţială putând fi reconstituita în orice moment. 

Rațiunea pentru care orice cîmp poate genera grupuri de atribute repetitive să fie trecut 
într-o relaţie separată derivă, pe de o parte, din complexitatea relației inițiale care poate deveni 
necontrolabilă sub aspectul gestiunii tuplurilor, iar pe de altă parte, se obțin relaţii mai simple 
care sunt mai uşor de încărcat si actualizat. 

2 Pasul imediat constă în a verifica relațiile prin prisma cerințelor formei normale doi 
2). 


Definitie: Se spune cà o relaţie R este în FN2 dacă şi numai dacă este în FNI şi dacă 
este asigurată dependenţa funcțională completă dintre atributele cheie şi atributele noncheie. 


Remarcăm faptul că problema dependenţei funcţionale complete se pune pentru relaţiile 
la care s-au definit chei concatenate (chei multi-atribut). Pentru relaţiile cu chei formate dintr-un 
singur atribut dependența funcțională completă este implicită. 


Se observă că anumite relații din figura 5.21 au chei concatenate, formate din două, < 
XRCCODM? si respectiv trei atribute, < NRC.CODM.LUNA>. În această situație se impune 
continuarea analizei relaţiilor, punând în evidență dependenjele funcționale dintre atributele 
cheie şi atributele noncheie. Dependențele funcționale corespunzătoare fiecărei relaţii din figura 
5.21 pot fi evidenţiate prin diagramele din figura 5.22. 


b) MATERIALE_CONTRACTATE 


Fig. 5.22. Diagrama dependențelor funcționale 


Studiind diagramele din figura 5.22. se poate observa că în relaţiile CONTRACTE, | 
MATERIALE_CONTRACTE şi ESALONĂRI LIVRĂRI este asigurată | 
funcţională completă dintre atributele noncheie si atributele cheie, ceca ce inseamnă că cele tei. | | 
relaţii sc găsesc si in FN2. 

Dacă în cadrul unei relaţii ar exista dependențe funcţionale parțiale ar trebui să 
descompunem relația de referinţă în subrelatii pentru a asigura dependenţa funcțională completă 
dintre atributele noncheie şi cheia relaţiei. 


Exemplu: Fic o relaţie R cu schema X;=(A,B,C,D,E.F,G) în care cheia relaţiei este dată 
de atributele A si B. Considerăm că atributele C D E depind de întreaga cheie A B, iar 
atributele F şi G depind doar de B (deci de o parte a cheii concatenate). Într-o astfel de situaţie 
se spune că relația R nu este în FN2 întrucât prezintă dependențe parțiale care produc şi ele 
anomalii de genul celor întâlnite la FNI. Anomaliile vor fi înlăturate prin descompunerea 
relaţiei R în două subrelatii cu schemele de definire Xa şi Xs, astfel: 

Ra cu X;7 (A,B,C,D,E) si 
Rs cu Xj (B,F,G] 
Relaţiile Ra şi R sunt in FN2, 


O altă situație care poate genera anomalii cu ocazia creării, actualizării şi exploatării 
iiim ae ae ovni cede Gil E ei aa 
atributelor față de cheia primară a relaţiei respective. Dependența tranzitivă apare în situația în 
care într-o relaţie există atribute noncheie care determină valori pentru alte atribute noncheie. 
Dacă analizăm relația CONTRACTE din figura 5.21 şi diagramele din figura 5.22 putem 
deduce prezenţa dependenţei tranzitive în cadrul acestei relaţii, redată în mod sugestiv în figura 
523. 


Depeadenje tranzitive care trebuiesc înl tarate 


Fig. 5.23. Dependente tranzitive 


Din figurile 5.22 si 5.23 se observă că în cadrul relației CONTRACTE (figura 5.21) există 
o dublă tranzitivitate, adică există două atribute noncheie (CODF si CODL) care determină 
valori pentru alte atribute noncheie, astfel: 

CODF determină valori pentru atributele noncheie DENF, TELEFON şi CONTB; 

-  CODL determină valori pentru atributele noncheie DENLOC si PREFIX. 

Tipurile de anomalii determinate de dependența tranzitivă sunt de genul celor amintite la 
ENI. 

Pentru a evidenția cât mai sugestiv anomaliile provocate de prezența dependenței 
funcţionale în cadrul relaţiei CONTRACTE din figura 5.21, vom recurge la asocierea de valori 
corespunzătoare atributelor relàfiei si aducerea acesteia la o formă tabelară (tabela 5.1). 

Pe baza datelor din tabela 5.1 vom căuta să evidenţiem câteva anomalii posibile a fi 
generate de prezenţa dependenței tranzitive în cadrul relației CONTRACTE, astfel: 

- Ștergere. În momentul expirării unui contract acesta urmează a fi şters din baza de 
date, ceca ce înseamnă că vor fi şterse informaţiile despre fumizori si localităţi, iar în 
momentul reincheierii contractelor va trebui să se reincarce toate informaţiile. În 
general, pentru unităţile economice, furnizorii se menţin cam aceiaşi de la un an la 
altul. Deci, în cadrul bazei de date informaţiile despre furnizori şi localităţi au o mare 
stabilitate. Într-o astfel de împrejurare se pune în mod firesc întrebarea: de ce să sc 
şteargă aceste informaţii de fiecare dată când expiră un contract ? Este de dorit ca 
informaţiile despre furnizori şi localități să fie păstrate în relaţii separate, În acest fel 
va fi evitată activitatea de reculegere şi încărcare a datelor despre furnizori; 


Tabela 5.1. CONTRACTE în ENI 
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atribut noncheie nu depinde în mod tranzitiv de cheia primară. 


o aduce în FN3 şi a scăpa astfel de anomaliile amintite anterior, relaţia CONTRACTE din - 
figura 5.21 va fi descompusă în trei subrelaţii, cu denumirile CONTRACTE (tabela 32,1 
FURNIZORI (tabela 5.3) şi LOCALITĂȚI (tabela 5.4). 


Tabela 5.2. CONTRACTE în EN 3 


i 
T0 


Inserare. Nu putem insera un nou tuplu referitor la o localitate particulară care are un 
cod, o denumire şi un prefix telefonic (de exemplu: CODL = 0465, DENLOC = 
DOMNEȘTI si PREFIX = 048), dacă nu avem cel puţin un contract cu un furnizor din 
acea localitate, deci dacă nu se dă şi valoarea cheii primare a relaţiei (nu se acceptă 
atribute din cheia primară cu valori nule-restricție de integritate). În mod analog, nu 1| 
putem insera un nou tuplu referitor la un furnizor particular până nu avem încheiat cu | 
acesta cel puţin un contract. Ori, este ştiut că prezintă interes să cunoaștem 
multitudinea furnizorilor potenţiali din domeniul de care ne ocupăm pentru a ios 
cu aceştia viitoare contracte; 


Redundanta datelor. Precizăm faptul că în activitatea curentă sunt foarte frecvente - 
situaţiile în care cu un fumizor se încheie mai multe contracte, ceea ce înseamnă că în | 
baza de date vor apare mai multe tupluri ce vor conţine aceleaşi informaţii referitoare 
la acelaşi furnizor (datele din tabelă încadrate prin linie întreruptă), deci redundanţă 
foarte mare a datelor cu multiple consecinţe negative, cum ar fi: 
e încărcarea acelorași date de mai multe ori, când s-ar putea încărca o singură dată; 
LI dacă se schimbă o informaţie referitoare la un anumit furnizor, va trebui să se „| 
actualizeze o multitudine de tupluri, când s-ar putea actualiza unul singur; i 
e o utilizare necorespunzătoare a suportului de memorie externă prin duplicarea | j 
informaţiei consumându-se spațiu de memorie suplimentar; 
e timp de calculator necesar prelucrării sporit datorită primelor două zoe 
menționate etc. i 
Relaiecc rci dependențe wanzitive nu sunt n oma normală tsi (25) 1 


Definiţie: O relație este în FN3 dacă şi numai dacă ea este în FN2 si dacă fiecare 


Conform definiţiei FN3, relaţia CONTRACTE din figura 5.21 nu este in FN3. Pentru a 


EL im LD de E 

[io [1000 

fis [010 12/11/2002 
120 [1020 [1571072001 | 
gm f 3/07/2001 


NEST 4435771 
11224561 |2116891 


4356916 377216 


Proiectarea bazelor de date relafionale 


Se observă că relaţiile din tabelele 5.3 şi 5.4 conţin un număr mai redus de tupluri 
datorită faptului că cele două tabele au fost obţinute prin proiecția tabelei 5.1 pe atributele 
fiecărei relaţii rezultate. În acest mod au fost eliminate dublurile de tupluri. 

Deci cele două relaţii rezultate din CONTRACTE (tabela 5.1) au un număr diferit de 
tupluri, totuşi nu s-au pierdut informaţii, tabela iniţială 5.1 putând fi reconstituită prin operația 
de joncțiune a tabelelor 5.2, 5.3, 5.4, de exemplu, printr-o frază SQL de genul: 


SELECT Contracte. NRC, Contracte. CODF, Furnizori. DENF, Furnizori CODL, 

Localitati. DENLOC, Furnizori. TELEFON, Localitati. PREFIX, Furnizori. CONTB, 

Contracte. DATAC, Contracte. VALC 

FROM (Furnizori INNER JOIN Contracte ON Furnizori. CODF = Contracte. CODE) INNER 
JOIN Localitati ON Furnizori. CODL = Localitati. CODL; 


din aplicarea căreia rezultă tabela originală: 


071 
1001/SM 


Rezultă că reducerea reprezintă o descompunere fără pierderi. De remarcat faptul că 
nivelul normalizări unei relaţii date este o problemă semantică şi nu de valori ale datelor care 
apar în acea relaţie la un moment dat. Nu este posibil doar să priveşti la valorile dintr-o 
relație, la un moment dat, sí să spui dacă relaţia este sau nu in FN3, ci este necesar să cunoşti 
semnificaţia datelor (dependentele funcţionale dintre atributele relaţiei). În figura 5.24 este 
sintetizată logica normalizării relaţiilor pentru primele trei forme normale. 


5.2.5. Forma normală BOYCE-CODD (BCNF) 


Considerăm următoarea relație cu mai mulţi candidaţi cheie: CONTRACTE=<NRC. 
FURNIZOR, MATERIAL> 

Cheia relaţiei este cuplul <NRC, FURNIZOR>; cu dependențele funcționale posibile 
prezentate in figura 5.25. Relaţia CONTRACTE poate fi considerată corectă în FN3 deoarece 
nici un atribut noncheie nu depinde de o parte a cheii sau de un atribut noncheie. 


Na 


Fig. 5.24. Procesul de Normalizare — prezentare sintetică 
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BOYCE si CODD sugerează că o relaţie cu doi sau mai mulți candidaţi cheie poate fi 
în două relaţii fără pierderi şi mai uşor de manipulat. 
i acest scop, definiţia FN3 a fost înlocuită de BOYCE şi CODD cu o altă definiţie 
' mai puternică, ce le poartă numele BCNF (Boyce-Codd Normal Form). 

Definiţia BCNF [Codd 74) este mai simplă decât FN3 deoarece nu face nici o referire la 
ENI si FN2 si nici la conceptele de dependență completă si dependență tranzitivă. 
+. Vom numi determinant un atribut, posibil compus, de care alte atribute sunt complet 
dependente funcțional. 

Definiţie: O relaţie R este în BCNF dacă şi numai dacă fiecare determinant este un 
candidat cheie. 

Conform definiției, relaţia CONTRACTE poate fi considerată si în BCNF, deoarece 
toate atributele ei formează o cheie şi nu există alţi determinanţi. Prin extensie, relația 
CONTRACTE poate să conţină redundante apreciabile, care, de obicei, conduc la probleme de 
actualizare. Reducerea redundantei se poate face prin descompunerea relației CONTRACTE în 
alte două relaţii. 

Orice relaţie poate fi descompusă in subrelații BCNF, fără să se piardă informaţii. Nu 
vom da această demonstrație ci vom sugera condiţiile în care o relaţie poate fi descompusă fără 
pierdere în două sau mai multe relaţii. Fie r o relație pe mulțimea de atribute X şi X, și X două 
submulțimi ale lui X astfel încât X-X;UX; şi Xo=XiriX2. Dacă r satisface dependența 
funcţională Xo-*X, sau dependenţa funcţională Xo—>X2 atunci descompunerea lui r in X; si X2 
este o descompunere fără pierdere (lossless). Altfel spus o relație r are o descompunere fără 
pierdere în două relaţii dacă mulţimea de atribute comune celor două relaţii este o cheie pentru 
cel puţin una din relaţiile în care s-a descompus. Pentru a fi corectă descompunerea trebuie să 
satisfacă întotdeauna două proprietăţi: 

- Descompunerea fără pierdere. Descompunerea fără pierdere asigură faptul că 
informaţia din relația iniţială poate fi reconstituită ca atare (fără false informaţii în plus 
sau fără pierdere de informaţie) pe baza informaţiilor din relaţiile rezultate prin 
descompunere. În acest caz prin interogarea relaţiilor descompuse vom obține acelaşi 
rezultat pe care l-am fi obținut prin interogarea relaţiei originale. 

- Conservarea dependenfelor. Conservarea dependențelor asigură faptul că relaţiile 
descompuse au aceeaşi capacitate de reprezentare a restricțiilor de integritate ca și relația 
originală şi astfel de a scoate în evidenţă actualizările ilegale: fiecare tip de actualizare 
permisă (respectiv, nepermisă sau ilegală) pe relaţia originală corespunde unei 
actualizări admise (respectiv respinse) pe relaţiile descompuse. 

acest context, pe exemplul nostru, relația CONTRACTE va fi descompusă în 
următoarele două relaţii: Ry = <NRC, MATERIAL> şi Ra = <MATERIAL, FURNIZOR> 

Relaţiile R, şi Ra sunt si ele în BCNF, iar din cadrul acestora dispare dependența 

funcţională (NRC, FURNIZOR) -> MATERIAL. Totodată, se apreciază că cele două relaţii Ry 
şi R2 sunt mai uşor de manipulat, iar în urma procesului de descompunere nu s-au pierdut 
informaţii, relaţia inițială CONTRACTE putând fi reconstituită prin joncțiunea lui R; cu R2 pe 
atributul MATERIAL. 


~ ul 
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5.2.6. Dependenţa multivaloare şi forma normală patru - Diferenţă. Dacă avem XY şi X—>—>Z atunci avem şi X2 Y-Z şi XYZ-Y. 
Revenind la problema normalizării, se observă că problema cu relaţiile de tipul 
MUNCITOR. din tabela 5.5 este că ele mențin dependențe multivaloare care nu sunt și 


dependențe Deci este de dorit înlocuirea relaţiei MUNCITORI cu relațiile Ra si Rz 
(tabelele 5.6 si 5.7). 


Tabela 5.6. R; în FN4 Tabela 5.7. Rz în FN4 


Până acum, în procesul normalizării, se poate constata că dependența funcţională ne-a 


Şi de această dată R. Fagin a demonstrat că o relaţie R (A,B,C) poate fi descompusă fără 
pierderi în două proiecţii R,(A,B) şi R2(A,C) dacă şi numai dacă relația R menţine dependențe 
multivaloare A——B şi A—-—»C (sau mai condensat A->—>B/C). Pe baza celor specificate, se 
poate trece la definirea formei normale patru (FN4). 

Definiţie: O relaţie R se află în FN4 dacă şi numai dacă oricind relația R menţine o 
dependenţă multivaloare, de tipul A—-»B, atunci toate atributele lui R sunt şi dependente 
funcționale pe A (A->—X, pentru toate X din R). 

Conform definitiei, relaţia MUNCITOR (tabela 5.5) nu este în FN4 deoarece implică 
două DMW între atributele participante la cheie: CNP-—>—>MESERII şi CNP-»—CAÁRTI. 

Deci, a patra formă normală cere ca relaţiile în forma normală trei să nu conțină două 
sau mai multe dependențe multiple. 

În contextul celor specificate, se poate afirma că relațiile Ri şi Ra (tabelele 5.6 si 5.7) 
sunt in FN4. 

Datorită faptului că o dependenţă funcţională este un caz particular de DMV, rezultă cà 
o relaţie în FN4 este în forma normală BCNF si deci în FN3. Acest lucru ne permite să afirmăm 
cà FNÀ se prezintă ca o îmbunătățire a formei BCNF. 

În scopul aprofundării, sugerăm si alte exemple de relaţii în cadrul cărora apare DMV, 
precum şi modul de trecere al acestora în FN4. 

Exemplu: Considerăm relaţia: 
MUNCITOR=<CNP, COPII CALIFICARE», 
unde un muncitor poate avea una sau mai multe 
calificări. Atributele COPII si CALIFICARE sunt 
independente, iar DMV sunt evidenţiate prin 
figura 5.26. Ceea ce înseamnă că relaţia penseo; 

MUNCITOR se va descompune în douà relații ce var fi în ENA: Ru = «CNP, COPII> , R; = 
CNP, CALIFICARE> 

Exemplu: Presupunem existența mai multor rute de transporturi auto ce pot fi parcurse 
de oricare tip de mașina aflată în dotarea unui parc auto. Totodată, presupunem un ansamblu 
de şoferi care sunt instruiți să conducă pe toate tipurile de maşini si pe orice cursă. În aceste 
împrejurări s-ar putea defini — o relație care să răspundă — cerinjei: 
CURSA=<RUTA,TIP_AUTO,ŞOFER>, unde TIP AUTO şi ŞOFER sunt atribute 
independente. Din cele precizate pot fi desprinse şi următoarele DMV: RUTA —— 
TIP_AUTO şi RUTA —— ŞOFER . Pentru trecerea relației CURSA in FN4, aceasta va fi 
descompusă în alte două relații conform celor două DMV precizate. 


Tabela 5.5 sugerează posibilitatea unei redundanle foare mari a datelor în baza de date 
Totodată se poate deduce insuficiența noţiunii de dependenţă funcţională care nu permite - 
sesizarea independenici ce există intre atributele MESERII practicate şi CĂRȚILE citi deo. 
anumită persoană. 1 

Pta, aceasta A gaulizeazi. nofjunea. de dependenfi. functionsll pein acces. de] 
dependență multivaloare (DMV). $ 

Definiție: Fie relația RO) cu X-{AnAzAn} şi W şi Y submulțimi de atribute 1 
AnAauswdm Se spune că W-—Y (Y depinde multivaloare faţă de W sau W determină o` 
multitudine de valori pentru Y) dacă fiind date valorile lui W există un ansamblu de valori T3 
asociate și acest ansamblu este independent de alte atribute Z= X-W-Y ale relaţiei R. 

De subliniat faptul cà dependența funcţională este un caz particular de dependenţă | 
multivaloare, în care mulțimea valorilor 


dependenței fiunejionale a mod similar i pentru DMV se pot defini câteva proprictii: 
Complementaritate. Fie X,Y şi Z trei atribute astfel încât X—Y-—2 si 
4 Y-—Z--—X. Atunci X-»— Y dacă şi numai dacă X->—Z. Sau, o altă exprimare, 
x dacă avem XY atunci avem şi X2—R-Y-X 
Reflexivitate. Dacă Y->—>X atunci XY; 
Creștere (augmentare). Dacă Z->—>W şi X» Y atunci ZW YZ; 
Tranzitivitate. Dacă X->—>Y şi Y——Z atunci X2.2-Y; 
Pseudotranzitivitatea. Dacă X—-—»Y şi YW——Z atunci XW——4Z şi YW; 
Reuniune. Dacă XY si X2 atunci X—YZ; 
Descompunere. Dacă X>—>Y şi Y3Z atunci X252, X 2 -Z, X--Z-Y; ` 
Replicare. Dacă avem X->Y atunci avem și XY; 
.- Contopire. Dacă XY si ZcY si există WCR si WOY=Ø şi WZ atunci X-Z; 
- Reuniune. Dacă avem XY şi X342 atunci avem şi X—YZ; 
~ dntersecfie. Dacă avem X—-—Y şi X->—>Z atunci avem şi X>—>YAZ; 
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5.2.7. Dependenţa joncțiune si forma normală cinci 


Până în prezent s-a presupus că singura operație necesară sau disponibilă în procesul d 
descompunere este înlocuirea unei relaţii prin două din proiecţiile sale. Această presupunere sa 
realizat cu succes până la forma normală patru. Apare ca o surpriză faptul că o relaţie poate s 
fie descompusă în două proiecţii cu pierderi, dare se descompune fără pierderi în trei sau mai 
multe din proiecţiile sale. 

Deci, nici dependenţa multivaloare, care a condus la descompunerea relațiilor în FN4, 
nu este suficientă pentru eliminarea problemelor de redundanţă și anomalii. 
a uie exemplificare, considerăm relaţia: BENEFICIARI MATERIALE FURNIZORI 
in tabela 5.8. 


Tabela 5. BENEFICIARI, MATERIALE, FURNIZORI 


Ees 


Atributele relației formează o cheie concatenată şi nu implică dependențe funcţionale 
sau dependențe multivaloare, deci este în forma normală patru. Să considerăm proiecţiile Ri, Rs, 
5i Rs ale relaţiei BENEFICIARI. MATERIALE, FURNIZORI din figura 5.27. 


> MATERIAL | .- FURNIZOR. 
Cablu Coaxial | COMPUTERLAND 


Cablu Electric CSI 
Cablu Coaxial CSI 


Fig 5.27. Proiecţiile relaţiei BENEFICIARI MATERIALE FURNIZORI 


Căutând să facem joncțiunea (Pa) relaţiilor vom constata că: 
BENEFICIARI MATERIALE, FURNIZORI = Rjb4yarnaL Ra: 
BENEFICIARI MATERIALE FURNIZORI = Ru PABEEFICURR 3; 
BENEFICIARI MATERIALE FURNIZORI = R>PSFURNIzORR3: 

Rezultatul jonctiunii relaţiilor R; şi Rz pe atributul MATERIAL apare ca în tabela 59. 
Se observă că relaţia din tabela 5.9 diferă de relaţia din tabela 5.8 prin apariția unui tuplu fals 
<ASE, Cablu Coaxial, COMPUTERLAND>. Acest tuplu fals este înlăturat de o a doua 
joncțiune a relaţiei rezultate din prima joncțiune (tabela 5.10) cu relația Rs pe atributele comune 
FURNIZOR şi BENEFICIAR. Deci, prin a doua joncțiune este reconstituită relaţia iniţială din 
tabela 5.8. Remarcăm faptul că rezultatul primei joncfiuni va fi același oricare ar fi perechea de 
proiecţii alese, adică aparitia unui tuplu fals. 
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Observând operaţiile descrise se poate da următorul enunţ: 
Enunţul e; - dacă perechea <CESTRIN, Cablu Coaxial apare în relația R; si perechea <Cablu 
Coaxial, CSI> apare în relaţia Rz şi perechea «CSLCESTRIN^ apare în Rs atunci tuplul 
<CESTRIN Cablu Coaxial, CSI» apare în relaţia BENFICIARI MATERIALE FURNIZORI. 


În acest caz relaţia iniţială (tabela 5.8) va fi joncțiune de R/PduareRat R2DOeENEFICURFURNIZORR3. 


Acest enunț poate fi formalizat astfel: 

Fie o relaţie R cu atributele X, Y, Z si Ri, Ra Ra subrelafii obfinute prin proiecţiile 
relației R pe diferite atribute ale acesteia pipi Ri = xy e (R); R=yz e (R) şi R3 = xz e 
(R). Dacă perechile «x, yj» ER; , <yuzr> eR? şi «xy, z> ER; atunci tuplul «xj, yj, z> apare 
în R, iar relaţia R va fi joncțiune de R, Ra Rs adică R=R DARPAR; 

Ținând cont de enunţul e; putem scrie următoarea restricţie asupra relaţiei 
BENEFICIARI MATERIALE FURNIZORI (tabela 5.8): 

Enunţul e; - dacă tuplurile: 

<CESTRIN, Cablu Coaxial, COMPUTERLAND>, 

<ASE, Cablu Coaxial, CSI» şi 

<CESTRIN, Cablu Electric, CSI> 

apar în relația BENEFICIARI MATERIALE FURNIZORI atunci apare sigur şi tuplul 
“<CESTRIN, Cablu Coaxial, CSI>. 

Această restricție este de tipul dependenței funcționale sau dependenței multivaloare. 
Deoarece această restricţie este satisfăcută numai dacă relaţia în cauză este joncţiunea anumitora 
din proiecţiile sale, a fost numită dependenţă joncțiune. 

Definiţie: Fie R o relaţie cu schema A = (AyAa.-, An) şi XiX3....X, submulfimii de 


(Aid: i). Se spune că există o dependenţă joncțiune *(X,X2,....Xm) dacă R este joncțiunea 
proiecfiilor (TI) lor pe XiX.. Xm adică: R-ITX, (R)PaITX4R)b4 ... 4X, (R), adică: 
n 
R- PII, 
isl 
Pentru exemplul de mai sus se spune că relaţia 


BENEFICIARI MATERIALE FURNIZORI satisface dependența joncțiune “*(R;, Ra, R3)". 

Teorema lui Fagin: "relația R(A, B, C) poate fi descompusă fără pierderi în Ri(A,B) si 
R:(B, C) dacá şi numai dacă R menţine dependenfele multivaloare A—-—9B/C", este echivalentă 
cu enunţul: "relația R(A,B,C) menţine dependenţa joncțiune "(AB AC), dacă şi numai dacă R 
menţine dependenţele multivaloare A—>— B/C". 

Din această echivalență rezultă că dependența multivaloare este un caz particular al 
dependenței joncțiune, după cum dependenţa funcţională este un caz particular al dependenţei 
multi valoare. 


Dependența joncțiune este forma cea mai generală de dependenţă, atât timp cât atenția 
noastră asupra dependenjelor se ocupă cu relaţii descompuse prin operaţii de proiecţie şi 
Tecompuse prin operaţii de joncțiune. 

= E 


Capitolul 5 


"forma normală de proiecție-joncţiune”. 
5.2.8. Supranormalizarea. Rezultatul normalizării 


A legati ez : base 
completă dacă proiectantul se așteaptă la adăugiri, modificări, si ştergeri destul vente. = 
Deci, atunci când datele au un caracter extrem de dinamic, În situaţia în care datele au un > 
caracter relativ static şi este de așteptat ca prelucrările să se rezume în special la cereri de 1 
consultare, atunci normalizarea se poate opri la BNCF. i 


care să maximizeze cererile pe o singură tabelă si să reducă numărul de jonciiuni ale mai multor 
tabele, 


eneral se pornește de la o relație universală ce descrie lumea reală si o mulțime de restricții | 
meat funcționale, dependențe joncțiune) pe atributele acestei relaţii. Apoi se reduce : 
sistematic relația la o colecţie de relaţii echivalente utilizând restricţiile ce ne ghidează în 
procesul de reducere. 


prin acesta ajungându-se la evitarea problemelor de actualizare. 


Relaţia BENEFICIARI MATERIALE_FURNIZORI, cu toate că este în ENA, implică 
totuşi o dependență joncțiune. Ca urmare, ea prezintă neajunsuri la actualizare. De exemplu, 
dacă se şterge tuplul «CESTRIN,Cablu Coaxial, CSI» trebuie şters încă un tuplu, pentru că altfel 
se contrazice enunţul e». Care alt tuplu trebuie sters? Trebuie ales oricare din cele trei. Pentru a 
scăpa de aceste neajunsuri, relaţia BENEFICIARI MATERIALE FURNIZORI trebuie 
descompus în relațiile specificate de dependenţă joncțiune, adici în subrelatille Ri, Ra, si Ry 
din figura 5.27. Procesul de descompunere se poate repeta până când toate proiecţiile sunt în 
forma normală cinci (FN5) — 

Kis Definiție: O relație R este în FNS dacă $i numai dacă fiecare dependență joncțiune este 
implicată printr-un candidat la cheie al relaţiei. ; Á j 
De exemplu, fie o relație R(Ai, Az, As, A4) având atributele Ai si Az candidate la cheie. 


Atunci este posibilă descompunerea fără pierderi a acestei relaţii in "(Ai Ao, Ai As, Ai iE 


În activitatea de proiectare a structurii bazei de date, se recomandă normalizarca 


Timpul de răspuns poate fi îmbunătăţit dacă relaţiile sunt utilizate în FNI, în formate _ 


În acest capitol s-a tratat succesiunea logică de normalizare completă a relaţiilor. În 1 


Procesul de reducere fi rezumat astfel: e H 
Se aleg pisse oa cale, Ak fa icri normală unu, care elimină E 
dependenjele funcţionale parțiale. Rezultă relafiiin forma normală doi; y. 

Se aleg proiectile relaţiilor FN2 care elimină toate dependentele funcționale tranzitive. ^ 
Rezultă relaţii în forma normală trei; : f 
Sc aleg prie relajilor în PR? cum aliniat dependengle female tn eare $ 
determinantul nu este candidat cheie. Rezultă relații în forma BCNF; i 
Se aleg proiecţiile relaţiilor BCNF care elimină dependențele multivaloare care nu sunt + 
şi dependențe funcţionale. Rezultă relații în forma normală patru; — 1 
Se aleg proiecţiile relațiilor in FN4 care elimină dependenjele joncțiune care nu sunt | 
implicate prin candidati cheie. Rezultă relații în forma normală cinci. 1 
Obiectivul general al procesului de normalizare îl constituie reducerea redundanfei 


| 
i | 
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5.2.9. Algoritmizarea primelor trei forme normale 


În literatura de specialitate exist o serie de preocupări pentru a demonstra că problema 


pormalizării poate fi rezolvată algoritmic . 


fi un 


date, 


Algoritmii elaborati pot fi implementafi pe calculator si în final, produsul rezultat, poate 
instrument util pentru administratorul bazei de date, în faza de proiectare logică a bazei de 
indiferent de tipul bazei de date. Produsul va specifica structurile de date (acele grupări de 


câmpuri de date, coloane sau atribute) pentru care nu apar anomaliile de actualizare. În acest 


context au fost elaboraji şase algoritmi, 


grupaţi sub denumirea de algoritmii de sinteză pentru 


primele trei forme normale. 


algoritmii sunt prezenţi într-o formă 


Algoritmii de sinteză. 


prelucrărilor efectuate de autori. Succesiunea algoritmilor, prezentată într-o formă sintetică, 


apare 


astfel: 
DFI. Eliminarea atributelor superflue. Fie f.(A1,. An] 9B şi g: A1... An) 9B două 
dependențe funcționale (DF), unde m<n. Atributele 4,..,.. 4, sunt denumite atribute 
superflue pentru f, deoarece atributele Aj... 4,, sunt suficiente a-l determina pe B. Aşa 
după cum sca mai arătat anterior, într-o astfel de situație se spune că P este dependent 
parțial de 4,,... 4, şi dependent complet de 4)....Am. Fie F mulțimea de DE dată la 
intrare. Se notează cu G mulţimea de DF rezultată prin eliminarea atributelor superflue 
din partea stângă a fiecărei DF din F. 
Acest pas este realizat de Algoritmul 1. 
DF2 Găsirea unei acoperiri neredundante. Fie G o mulţime de dependențe 
funcţionale. Se numeşte închiderea lui G şi se notează cu G°, mulțimea tuturor 
dependenţelor funcţionale (DF) care sunt obținute prin aplicarea succesivă a axiomelor 
lui Armstrong (paragraful 5.2.3) asupra mulțimii G. Mulțimea H se numește acoperire 
neredundant a lui G dacă H'*G' şi dacă nici o submulțime J a lui H nu are 
proprietatea J' «G^. Deci, H este o acoperire minimă a lui G. În acest context se găseşte 
o acoperire neredundantă, H, a lui G, eliminând DF redundante din G. 
Acest pas este realizat de Algoritmul 2. 
DF3. Partiţionarea. Se împarte mulţimea H în grupuri de DF astfel încât toate DF 
dintr-o grupă să aibă părţile stângi identice. 
DF4. Îmbinarea cheilor echivalente. Pentru fiecare pereche de grupuri din H, dacă 
există în H” o bijecţie între părțile lor stângi, atunci se unesc cele două grupuri. 
Construieşte mulţimea J. Acest pas este realizat de Algoritmul 3. 
DES. Eliminarea dependenjelor tranzitive, Găseşte o mulțime H'CH astfel încât 
(HJ) =(H+)* si nici un alt subset al lui FI mu are această proprietate. Adaugă fiecare 
DE din J în grupul corespunzător al lui H'. Acest pas este realizat de Algoritmul 4. 
DF& Construirea relaţiilor. Pentru fiecare grup al lui FH" se construieşte o relaţie care 
Conţine toate atributele din acel grup de DF. Acest pas este realizat de Algoritmul 5. 
În continuare va fi prezentat fiecare algoritm. 


Algoritmul 1. Elimină atributele superflue în următoarea succesiune: 


“Introducerea dependenjelor funcţionale. Se introduce în sistem mulfimea dependentelor 
funcţionale, F. DF sunt memorate astfel: atributele din partea stângă în variabilele LS(), 
iar atributele din partea dreaptă în variabilele AS(J), 

Aducerea la forma canonică redusă. Dac există două sau mai multe DF în F, cu părţile 


F. 
- Formarea funcției g. Pentru fiecare DF din F' se scoate succesiv câte un atribut din 


partea stângă. Dacă funcția rezultată este în forma canonică (care are în partea dreaptă s - 
+ 


pentru toate cele k funcţii. 
Algoritmul 2. Găseşte o acoperire neredundantă. 
Presupune: É " 
- Formarea funcției g. Se ia fiecare funcţie din G. dacă aceasta este în formă canonică 
reprezintă funcția g, dacă nu este adusă la forma canonică (formându-se k funcţii: 
Bi). 
- Formarea mulțimii G-(g]. G:= G-{g}; 
- Verificarea enunţului ge(G-[8)) ; 
- Se aplică algoritmul 6. 
Dacă g e(G-(g))' atunci g este un DF redundant în G^ si sc reia de la pasul 1. 
Dacă g e(G-(g))' rezultă cà g nu este redundantă în G. G:= G- {g}. Se reia de la pasul 1. 
Dacă G a fost adusă la forma canonică, paşii 2 şi 3 se execută pentru fiecare funcție g, iar 
concluziile de la pasul 3 se trag pe baza celor k ecuaţii ale pasilor 2 si 3. 
Rezultatul algoritmului este acoperirea neredundantă, H, a lui G. 
Algoritmul 3. îmbină cheile echivalente. 
- lnifializarea funcției J: J=2: , } 
- Formarea funcției g. Pentru fiecare pereche de grupuri din H, H; yi Hj, cu părțile stângi 
X şi respectiv Y, se formează funcțiile: 
gX>Y 
grY—X 
Pentru fiecare se execută pasul 3. p. 
- Verificarea enunfului g €H'. Se aplică algoritmul 6. 
- Formarea funcţiei J. Dacă gi si ga sunt în H^ (deci bijecţia X«»Y eH") atunci: unesc H 
şi H; într-un singur grup (acest grup va avea două chei:X și Y) J:=/+X-9Y, YX 
Merge la pasul 5. Dacă g; si g nu sunt în H” se reia de la pasul 2. e 
- Verifica dependentele parțiale dintre X şi Y. Pentru fiecare A €Y, dacă există X'e4 în H 
atunci elimină din H această dependență. Pentru fiecare BEX, dacă există YeB în H 
atunci elimină din H această dependență. 
Algoritmul 4. Verifică dependenyele tranzitive. 


- Eliminarea dependenjelor tranzitive. Pentru fiecare DF din H se ia fiecare c 
combinaţiile posibile dintre atributele din partea dreaptă si verifică dacă există 
dependențe funcţionale între ele în H. Dacă există se elimină atributul/atributele (cele 
din partea dreaptă a dependenței formate) respectiv din aceea DF. Se reia de la pasul 1. 

- Se adaugă fiecare DF din J în grupul corespunzător din H. Rezultă mulțimea H; 


Algoritmul 5. Construirea relaţiilor. < 


a 
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Construirea relaţiilor. Pentru fiecare grup al lui H' se construieşte o relaţie care conține 
toate atributele din acest grup de DF. 

Desemnarea cheii/cheilor relaţiilor. Cheia/cheile relaţiilor sunt formate din atributele 
din partea stângă a DF din fiecare grup din H'. 


Algoritmul 6. Verifică dacă g aparține închiderii G*, adică g €G* si presupune: 


Formarea mulțimii M. Mulțimea M este formată din elementele 1,2,.,n, unde n 
reprezintă numărul de DF la intrarea în algoritmul 6. 

ROOTS:=2 

Formarea mulțimii TEMP. Mulțimea TEMP este formată din atributele din partea 
stângă a DF g. 

Verificarea mulțimii TEMP. Dacă TEMP=0 atunci geG”. Se termină algoritmul. Dacă 
TEMP # 0 se continuă de la pasul 4. 


Construirea derivărilor. Pentru fiecare I din M se verifică dacă LS(1) ROOTS. Dacă da 
atunci TEMP: - TEMP RS() si Me*M-I. Verificarea rădăcinii a lui g aparține mulţimii 
TEMP, atunci funcția g aparține închiderii. TEMP: «£f; altfel algoritmul sc continuă de 
la pasul 3. 


5.3. Calitatea schemelor 


Schema este o descriere, în termenii modelului bazei de date, a conceptelor şi structurii 


informatiilor unei aplicaţii reale. Ea poste fi structura actuală a bazei de date. O schemă descrie 
toate instangierile posibile ale bazei de date pentru o aplicaţie reală dată. 


Cea mai importantă acţiune a proiectării bazei de date este proiectarea unei scheme de 


calitate cu restricţiile SGBD-ului disponibil si al modelului bazei de date. O schemă de proastă 
calitate oferă posibilitatea corupției datelor, modificărilor greoaie si incorecte, schimbărilor 
greoaie la apariţia/ dispariţia conceptelor lumii reale. 


O schemă este de cea mai bună calitate sau adecvată conceptual dacă satisface 


următoarele criterii: 


Schema descrie conceptele aplicaţiei reale în mod natural: 
* schema descrie obiectele, categoriile şi asocierile așa cum sunt în lumea reală; 
e utilizatorii pot translata uşor ideile în ambele direcţii dintre conceptele schemei 
şi conceptele naturale ale aplicaţiei. 
Schema este non-redundantă sau are o redundanță minimă si controlată. Eliminarea 
redundanjei nu este făcută în scopul economiei de spațiu de stocare. Redundanfa din 


acestora (subschemele bazei de date). Dacă redundanja nu poate fi eliminată complet 
atunci ea trebuie controlată prin intermediul unor restricţii de integritate sau rutine prin 
care să se forțeze actualizarea simultană a informaţiilor, indiferent de locul unde este 
cerută aceasta, în toate locurile in care există. 

Schema nu trebuie să impună restricţii de implementare adică trebuie să surprindă orice 
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acceptat de majoritatea SGBD; "m 

- Schema trebuie să fie flexibilă (dacă apar schimbări in conceptele aplicațiilor reale atunci 
în schemă nu trebuiesc făcute schimbări drastice). 

- Schema trebuie să fie conceptual-minimală, adică nu trebuie să conțină concepte care 
sunt irelevante în aplicaţiile reale și limitează acumularea informaţiilor care Sunt 
irelevante în această lume reală. ; 

O bună schemă conceptuală trebuie să posede următoarele proprietăți pentru a i se putea - 
verifica calitatea: i 

- Corectitudine. O schemă conceptuală este corectă atunci când utilizează corect. 
elementele constructive puse la dispoziție de modelul conceptual. C si în limbajele de` 
programare ne confruntăm cu două categorii de erori: 

* sintactice, referitoare la utilizarea nepropice a elementelor constructive; 

* semantice, referitoare la utilizarea corectă a elementelor constructive dar! 

incorect din punctul de vedere a definiției lor; 1 

Corectitudinea schemei este verificată prin inspectare şi comparare a conceptelor | 

prezente în schema cu cerinţele şi definițiile constructorilor modelului conceptual $ 
utilizat. , 

= Completitudine. O schemă conceptuală este completă atunci când include concepte care - 
reprezintă toate cerințele de date si permite execuţia tuturor operaţiilor incluse în. 
cerințele operaţionale, Completitudinea schemei poate fi verificată prin controlarea- 
faptului că sunt reprezentate toate cerințele de date printr-un anumit concept prezent în | 
schemă şi că toate conceptele implicate în operaţie pot fi atinse prin “navigarea” pe. 
schemă. 


oerte VS 


= Relevanjá. O schemă conceptuală este relevantă atunci când reprezintă cerințele întrun, 

mod natural şi uşor de înțeles. În aceste condiţii schema trebuie să fie, pe de o parte, 

auto-explicabilă, de exemplu, prin denumirile relevante date conceptelor iar, pe de altă $ 

parte, să aibă o estetică care să ajute relevanța. Poate fi obținută o bună estetică a^ 

schemei care o face si relevantă respectând cerințele: 

* se aranjează reprezentarea grafică a schemei pe un caroiaj alegând ca elemente ^ 
centrale pe acelea care au cele mai multe legături cu celelalte; 

* se vor utiliza numai linii orizontale si verticale si se vor realiza, pe cât posibil, 

cât mai puţine intersecții; 
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Partea manipulativà a modelului relajional constă dintr-un set de operatori cunoscuţi sub 
numele de algebra relafionalà împreună cu un operator relafional de atribuire, Operatorul de 
atribuire asignează o expresie arbitrară a algebrei unei alte relații, 

Algebra relațională a fost concepută de către E.F.CODD ca o colecție de operaţii 
formale asupra relaţiilor. Fiecare operație a algebrei relational are una sau mai multe relaţii ca 
operatori şi produce ca rezultat o nouă relație. Această relaţie poate fi la rândul său subiectul 
unor viitoare operaţii algebrice. Operanzii oricărei operaţii pot fi sau relaţii simple sau expresii 
cu relaţii. Codd a definit o mulțime de astfel de operații si a arütat că acestea sunt complet 
relaţionale, în sensul cà ele au cel puţin puterea de regăsire a calculului relafional. 

Algebra relafionalà utilizează două grupe de operatori: operatori tradiționali pe mulțimi 
şi operatori relaţionali speciali. Aceste grupe de operatori permit efectuarea operațiilor 
corespunzătoare lor. 


6.1. Operații tradiţionale pe mulţimi 


În categoria operaţiilor tradiționale pe mulțimi includem reuniunea, intersecția. 
diferența şi produsul cartezian. 

Aceste operaţii au fost modificate pentru a opera mai degrabă pe relații decât pe 
mulțimi. Pentru operaţiile enumerate, cu excepția produsului cartezian, cele două relaţii operand 
trebuie să fie compatibile cu reuniunea, adică, să fie de același grad si atributele lor să aparțină 
aceloraşi domenii (nu este absolut necesar ca atributele cores; să aibă aceeaşi 
denumire, acest lucru fiind cerut de platforma SQL utilizată). În situaţiile reale operațiile 
algebrei relaționale nu sunt utilizate singular. De cele mai multe ori ele implică o combinație de 
astfel de operații. De exemplu, operaţia de reuniune, necesită două selecţii (identice ca 
Structură a tabelelor rezultat) între care se efectuează efectiv reuniunea. 

SGBD-urile actuale care implementează limbajul standard de manipulare a bazelor de 
date SQL, în una din versiunile sale, nu pun la dispoziție în mod obligatoriu comenzi distincte 
pentru realizarea operațiilor relaționale, ci o singură frază cu structura generală: 


SELECT ce_coloane_dorim_să_apară_în_răspuns 
FROM din ce tabel 
(WHERE ce. condigii trebuiesc indeplinite de rânduri i pentru a fi luate in considerare] 


care poate fi exprimată astfel: 


Select ri A, ri Ar By sr Bm Ej) Ex), En) re Wy. n Wn $ 


from Tura, -sa = Prin construcţia Balanta.* am desemnat toate coloanele din tabela balanța Balanta. 
[where <condiţie joncţiune> [filtru» ]][clauze opționale]; nefiind altceva decât specificatia prin care se spune de ce tabelă aparțin coloanele respective. 
E Exemplu: Reuniunea datelor din jurnalul curent cu cele din jurnalul arhivat în vederea 

unde: vizualizării fişei unui cont (în cerere nu se specifică acum filtrul de selecţie): 
- prin A, B,..., W; am desemnat atribute din schemele de relaţie corespondente r4 
- prin E) am desemnat expresii definite pe mai multe coloane din aceste relaţii sau orice alte i Select Jurnal.* From Jurnal 

expresii conținând referiri la funcții definite de SGBD sau utilizator, constante, expresii t Union 

aritmetice sau logice etc; Select Istorie Jurnal.* From Istoric. Jurnal; 
~ prin construcţiile de forma r;4; am specificat faptul cà atributul 4, este unul din atributele e 

din schema de relaţie a relaţiei r, Intersecţia relaţiilor rX) şi ra(X) este mulțimea tuturor rândurilor (tuplurilor) ce 

aparțin atât lui r, cát şi lui ra. 


Reuniunea a două relaţii ri) şi rX), cu aceeaşi schemă de definire X, reprezintă 
mulțimea tuturor rândurilor (tuplurilor) t aparținând lui r; sau lui rz sau ambelor. Rezultatul 


reuniunii este o nouă relaţie rs, cu 7309=r1(090r209. EN 
caii 
a) 


b) 
Fig. 6.2. Intersecţia relaţiilor 


b) 


a) 
Fig. 6.1. Reuniunea relaţiilor 


DDP. DIDP, ADRESA, TELEFO! 
Tam Cu c eu" 


Sub formă grafică reuniunea poate fi sugerată ca in una din figurile 6.1. a) sau b). În 


figura 6.1. b) relaţia rezultat r este reprezentată grafic ca partea din relaţiile de origine ri si n DRUMURI «DR, DRUM, KMI, MI KMS, MS, LUNGIME, INCEPUT, SFIRSTT> 
care au aceeași schemă de definire. C2 CA, NINA NA NA N73 — CAS cu 


Pentru exemplificare considerăm relaţiile Ry si Ra cu schemele de definire 
xor-taan=(2 t MIL b2 cl). Aplicánd operatorul de reuniunc a 


a mad LoNCDE- 

celor două relaţii va rezulta o nouă relație ry cu aceeaşi schemă de definire Z= (A, B, C) cu Ma 

d B el 
n=|al B2 el | ceea ce poate fi exprimat in SQL astfel: 

a2 d | DRENURI <DR, DRUM, KMI, MI, KMS, MS, PARTE, AMPLASARE, TIP_DREN ADINCDIP- 

TE CA NINA NINA C3 en CD Ng? 

SELECT r1.* FROM r1 Fig. 6.3. Exemplu de Subschema 
DTE * FROMr; Acest tip de operație permite gruparea într-o altă relaţie 7; a tuturor elementelor comune 


Celor două relaţii r; şi ra, ceea ce grafic este sugerat în figura 6.2 a) sau b). 
unde prin * s-au desemnat toate atributele schemei de definire a relaţiei specificate. 


Exemplu: Reuniunea datelor din balanța curentă (Balanta) cu datele aferente balanţelor d bl cd 
arhivate în vederea analizei evoluției conturilor: Fie n=|al 52 cl | şi r,=(a2 B2 cl), intersecţia relaţiilor ri cu rz apare astfel: 
Select Balanta.* From Balanta | Bro nus 
UNION nri rzadică r =(a2 52 d) 
Select Istoric_Balante.* From Istoric_Balante; 
izz 7 123 
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Exemplu: Lista drumurilor internaţionale care se regăsesc descrise în drumuri nafi 
conform definiţiei din subschema bazei de date din figura 6.3. poate fi obținută cu fraza: 

SELECT rl dr, rl.drum, rl.kmi, rl.mi, rl.kms. rlms FROM drumint r] 

INTERSECT 

SELECT r2.dr, r2.drum, r2. kmi, r2.mi, r2.kms, r2 ms FROM drumnat r2; 


Diferența dintre două relaţii r; şi rz cu aceeaşi schemă de definire Xj-X», reprezintă 
mulţimea tuturor rândurilor (tuplurilor) ce aparțin lui rı, dar nu aparţin lui ra. Relaţia rezultată 


va avea aceeaşi schemă de definire Xy-X,-X3. 1 
E] 
| 
1 
1 
i 
i 

Reprezentarea grafică a diferenței poate fi sugerată ca în figura 6.4 a) sau b). 3 
al B el E 

Fie &-|ab b2 cl| şi n=(a2 b2 cl) diferema dintre n sino ese] 
a2 b2 el 


T 


[a ae 
3" lab B2 el, 
Exemplu: Pentru subschema din figura 6.3 lista porțiunilor de drum care nu au drenuri: 
SELECT idr, drum, i.m, imi, kms, ims FROM drumuri I 
MINUS 
SELECT d dr, ddrum, d.m, d mi, dkms, dms. FROM drenuri d 


Aşa cum am enunțat în paragrafele anterioare operatorii de reuniune, intersecţie şi, 
diferenţă nu pot fi aplicaţi decât asupra relaţiilor compatibile cu reuniunea, adică tabele cu 
același număr de atribute, cu atributele corespondente definite pe aceleași domenii, denumite y 
fel si date în aceeași ordine. Dacă atributele îndeplinesc celelalte condiții exceptând ordinea ed 
află în poziţii diferite) acest caz poate fi rezolvat simplu prin specificarea lor in frazele SQL în 
aceeași ordine. $ 

În cazul in care atributele corespondente au denumiri diferite dar îndeplinesc celelalte 
criterii compatibilizarea lor cu reuniunea poate fi realizată precedánd operaţia respectivă cu 8, 
operati de redenumire a lor. De exemplu dacă dorim să vedem prin ce conturi s-au consemnat 
operaţiunile firmei în luna curentă ar trebui să utilizäm relația Jurnal Curent şi să efectuăm 0. 
reuniune a coloanelor ContDB şi ContCR. Pentru a rezolva această cerere vom utiliza un 
operator de redenumire (introdus în SQL prin clauza AS) a cărui aplicare va precede realizarea. 
efectivă a operaţiei de reuniune, astfel: 


Select Distinct ContDB AS Simbol From Jurnal_Curent 
UNION 


124 


Algebra relațională şi calculul relational 


Select Distinct ContCR AS Simbol From Jurnal Curent; 


Operatorul de redenumire, pe care îl vom nota cu 1), poate fi definit astfel: 
Fie r09 o relaţie definită pe mulțimea de atribute X si Y o altă mulțime de atribute cu aceeaşi 
cardinalitate cu X. Fie 41,45... o ordonare a atributelor din X şi By,Bs.... By o ordonare a 
atributelor din Y care asigură faptul că A; si B, (î=1,2,...„k) sunt definite pe acelaşi domeniu. În 
aceste condiţii redenumirea, notată 


Ts. € Ad, 


prin 


confine un tuplu t' pentru fiecare tuplu t dinr, definit astfel: t' este un tuplu din Y şi t [Bj] - t [A] 
pentru i71, Această definiție confirmă faptul că schimbările care au loc sunt schimbări 
ale denumi ibutelor, valorile acestora rămânând nealterate şi asociindu-se noilor atribute. 


Exemplu: Dorim să reprezentăm relațiile paterne si materne ale unui arbore genealogic 
prin relațiile: 


Paternă 

[Taa 72 Copil 
| Adam. Cain 
„Adam — | Abel 
Abraham | Isac 
[Abraham | Ismael 


Fig. 6.5. Relaţiile Paternă şi Matemă 


Dacă dorim să obținem o relație care conține părinţii si copii acesta ar fi o reuniune a 
celor două relaţii definite anterior si instinctiv am avea pentru ea coloanele (Párinte,Copil). 
Coloana Părinte este denumită în una din relaţii Tată iar în cealaltă Mamă făcând astfel 
imposibilă reuniunea prin faptul că nu au același nume, Aplicarea operatorului de redenumire 
va face posibilă reuniunea lor conform modului ilustrat în figura 6.5. Această operaţie poate fi 
descrisă în SQL astfel: 


Select Tată As Părinte, Paternă Copil From Paternă 
Union 
Select Mamă As Părinte, Maternă Copil From Maternă 


Produsul cartezian a două tabele (relaţii) ri şi rz reprezintă mulțimea rândurilor 
(tuplurilor) t, astfel încât un rând (tuplu) t este concatenarea unui rând (tuplu) p er, cu un rând 
(tuplu) qerz 


Să considerăm relaţiile r; cu schema de definire X = (A) şi r cu schema de definire Y = 
(B). Se poate obține o nouă relaţie rs ca produs al celor două, cu condiţia ca: XAY = Ø. Astfel 
relația r = r; x ra = (a, b) | a; € ri şi b; € 12) cu schema Z dată de reuniunea schemelor de 
relaţie ri şi ra, adică Z=XUY. În exemplul din figura 6.6 b) elementele relaţiei rezultat sunt 
mulţimea perechilor [(a,b), (*.y;2)], iar schema de definire pentru r; va fi dată de reuniune 
schemelor relaţiilor rj şi ra, adică Z=(A, B}. 


nn osul ge ec oaia OC ———— 


a EEE ae 


Părinte COPIE 
Adam Cain E. 
Adam Abel 3 
Abraham — |lsac 
Abraham | Ismael 
Eva Cain 
Eva Set BEN X 
CNN I S DU EMI |n 
Hager d CABLU COMPUTERLAND | BUCURESTI 
Fig. 6.5. Utilizarea operatorului de ic COAXIAL 
redenumire 


EN IRI Wem ed 
COAXIAL 

EST GU E ial d] 
ELECTRIC 

EE ["|*.pm[m.. [mm] 

ELECTRIC 


Reprezentarea grafică a produsului cartezian a două relaţii rı sí a este sugerată în figura 
6.6 a) sau b). 


PRODUCT 


Ri pem 
Deci, semnificaţia practică a produsului cartezian corespunde generării unei tabele 
(relaţii) din două tabele (relaţii) prin combinarea fiecărui rând (tuplu) din prima relaţie cu 


R } Es x bu E ficare rând (tuplu) al celei de a doua tabele (relații). 
[:] [>] a Produsul cartezian al cele doua relaţii se exprimă în SQL astfel: 
in] b 
$ SELECT * FROM MATERIALE, FURNIZORI; 
3) " = 
Fig. 6.6. Produsul cartezian al » TW. Exemplu: O fabrică producătoare de automobile produce toate automobilele sale într-o 
relaţiilor fază unitară de culori. Dacă dorim să menţinem o evidenţă a acestora sub forma : 


În general, această operaţie se utilizează destul de rar singulară. Ea este o 
operaţie de pregătire a datelor în vederea realizării operaţiilor speciale ale algebrei relaţionale. 
Utilizarea sa singulară este uzuală în cazuri similare următoarelor exemple. 


Exemplu: Presupunând două relaţii cu denumirile de MATERIALE şi FURNIZORI. 
având schemele de definire: 
M = (CODM, DEMAT, UM, PRET-LIVR) si F = (CODE, DENFURNIZOR, LOCALITATEA) 


Asociind câteva valori atributelor celor două relații se va ajunge la forma tabelază + 


2 Ese] 
UU EET EC a 
[Oz Tcantumrscmuc | wr] —i5-—] 


Esci valorile atributelor Denumire-Auto, Tip-Auto, Cilindri se vor duplica de atâtea ori câte 
doi avem. Pentru a evita această situație în baza de date vor fi menținute două tabele: 
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AUTO 


coup paie [a 
|piciaSuperțova | Bertins | 1400 | 


Cu aceste precizări definiția selecţiei este: i 
Selecţia Op (r) produce o relaţie cu aceleaşi atribute ca r şi care confine numai acele 
tupluri din r pentru care F este evaluată la Adevărat. | 


În figura 6.7 b) se sugerează faptul că din multitudinea rândurilor tabelei se extrag 
numai acelea hagurate. Numărul de tupluri din relația rezultată (cardinalitatea tabelei rezultat) 
este mai mic decât (sau cel mult egal cu) cel al relaţiei operand. | 


Obtinerea unei liste cu toate tipurile de automobile si culorile în care se produc, poate & 
realizată prin produsul cartezian dintre: AUTO x CULOARE ceea ce permite T 


iniţiale AUTO printr-o frază de genul: 
SELECT AUTO.*, CULOARE. * FROM AUTO, CULOARE; 


6.2. Operații relationale speciale 


a) 


) 
Fig 6.7. Operația de Selecție 


În această categorie de operații vom include selecția, proiecția, joncțiunea (join) și 
diviziunea. 

Exemplu: Presupunem o relajie MATERIALE cu schema de definire : 
X-(CODM,DENMAT,UMPUSTOC-EXISTENT,STOC-NORMAT) şi valorile -asociate 
conform tabelei 6.5. 


Operatorul algebric de selecție produce o subrelație r' (subset) "orizontală" a unei 
relații r date, supuse operației de selecție. Subrelaţia obținută va confine multitudinea 
rândurilor relației supuse selecției care satisfac un predicat P specificat. Relația rezultată va 
avea aceeași schemă de definire ca şi relaţia operand. 1 

Fie o relaţie r cu schema X; A un atribut aparținând lui X, a un element al atributului A 
şi t multitudinea rândurilor (tuplurilor) ce satisfac o anumită condiție. Operația de selecţie poate 
fi exprimată astfel: r' A) = (ter | 4[4] = a). 

Reprezentarea grafică a operației de selecție este redată în figura 6.7. Predicatul P poate 
fi o expresie logică care poate combina condiţii simple cu ajutorul conectivelor logice AND (^). 
OR(V) şi NOT(-). 

Operația de selecție poate fi notată astfel O(7), unde F este funcția (expresia) 
descrie predicatul iar r este relaţia. Mai precis, fiind dată o relaţie rø, o formulă pena 
(expresia predicatului) F pe X este o formulă obținută combinând condiții atomice de tipul 4 
sau A6c cu ajutorul conectivelor A (ȘI - And), v (SAU - Or) si — (Nu — Not), unde: 

7 Oeste un operator de relație (=, >, <, <=, >=;©, Like, Between etc); 

- A şi B sunt atribute din X care sunt compatibile (adică comparațiile 0 au sens şi 
pe valorile domeniilor lor); 

- € este o constantă compatibilă cu domeniul lui A. 


Tabela 6.5 MATERIALE 


Presupunem că dorim să selectăm toate materialele ale căror coduri sunt mai mici decât 
1116 si au stocul existent mai mare decât stocul normat. În urma operației de selecție va rezulta 
subrelația redată în tabela 6.6. | 


Tabela 6.6. MATERIALE - SELECTATE 
Lum [casrucoaxmr [xg [ie] —— 10x0| î1coo| 
[1s [conector mama [Buc fso] — — — 2| — — 309] 


Exemplu: Se solicită listarea tuturor drumurilor judeţene din județul Argeș (figura 6.3). 
În acest caz tabela implicată, la nivel CESTRIN-AND, este DNJUD, iar condiția (predicatul) de 


Fiind dată o formulă F şi un tuplu 1, formula este evaluată la o valoare logică (booleană. 
sau de adevăr) astfel: 


- 40B este evaluată la Adevărat pe ter% dacă şi numai dacă /[A] este în relația 8 cu 1/8], 
(de exemplu A=B este adevărat pe t dacă şi numai dacă 1/4] -1/B]); 

-= A0ceste evaluată la Adevărat pe t dacă şi numai dacă 1/4] este în relaţia 0 cu c; 

= FIVFa FIAFa ^F, au un înţeles uzual. 
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selecţie este JUD = "AG". Prin acest predicat vor fi selectate din tabelă numai acele rânduri care 
conţin în coloana JUD valoarea AG ceea ce se exprimă în SQL astfel: 
SELECT * FROM DNJUD WHERE JUD="4G: 


Se solicita listarea tuturor autostrăzilor din județul Argeș (figura 6.13). Este implicată 
tabela DNJUD, iar predicatul de selecție implică coloanele JUD (județul) şi DR (categorie 
drum) astfel: JUD = "4G" şi DR = "A " exprimat în SQL astfel: 

SELECT * FROM DNJUD WHERE JUD='AG' AND DR='4 '; 

Se solicită extragerea din jurnal a tuturor operaţiilor prin Casa în Lei. Este implicată 
tabela Jurnal iar condiția de selecţie este ca fie ContDb fie ContCr să fie egale cu 5311, ceea ce 
se exprimă în SQL prin: 

Select * From Jurnal Where ContDb-"5311" Or ContCr="5311"; 

Se solicită extragerea din balanță a conturilor din clasa de cheltuieli (6). Va fi implicată 
tabela Balanta iar condiţia de selecție este dată de prezența, pe prima poziţie din simbol, a 
codului clasei (6) ceea ce poate fi exprimat în SQL ca: 


Select * From Balanta Where Simbol Like "6*"; 


Proiecţia unei relaţii r cu schema X-(A1A5.....4,) pe atributele 41,43. ma, (unde 
m=n) produce o relație r' cu schema X'=(41,Aa...+An), obținută prin selectarea atributelor 
specificate şi eliminarea tuplurilor duplicate. 


Pentru operația de proiecție sunt consacrate următoarele notații: 
Tr), 

Tla am 

RÍA, As. An] 


PROJECT (r/A)A3........ An. 


În figura 6.8 este redată reprezentarea grafică a operației de proiecţie. 

O definiţie alternativă pentru proiecție este următoarea: fiind dată o relație (X) și o 
mulțime YcX atunci proiecția lui r pe Y, indicată prin Tly(r), este mulțimea tuplurilor din Y 
obținute din tuplurile lui r considerând numai valorile pe atributele Y, adică IT,(r)- ([Y] | t6r). 
Proiecţia relaţiei Ty(r) confine acelaşi număr de tupluri ca si r (are aceeași cardinalitate) dacă si 
numai dacă Y este o supercheie pentru r. 


d 


Pig 3. Operația de Proiecţie 


b) 
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În figura 6.8 b) se sugerează faptul că din multitudinea coloanelor tabelei se extrag 


numai acelea haşurate, proiecția producând o descompunere verticală a tabelei de origine. 
Exemplu: Considerând relația MATERIALE-CONTRACTATE cu valori asociate 


- conform tabelei JT. 

„Tabela 6.7. MATERIALE CONTRACTE 

prez [CANT-CONTR] 
[ nn[i[ 10] 


Prin aplicarea operatorului de proiecție asupra atributului CODM/ aparținând relației 
"MATERIALE-CONTRACTE, deci Tlcoow(MATERIALE-CONTRACTATE) se objine: 


CODM$ 
4111 
1112 
1113 


Se observă că s-a obținut lista materialelor contractate, din care dublurile au fost 
excluse, 

Se cere indicativul drumului public si lungimea pentru drumurile care leagă localităţile 
BUCURESTI-PITESTI (schema din figura 6.3). La rezolvarea acestei cereri se va utiliza tabela 
DRUMURI din care vor fi selectate atributele (coloanele) DRUM și LUNGIME la care se 
aplică condiția (predicatul) de selecție (INCEPUT="BUCURESTI" si Sfürgit-"PITESTI") sau 
(INCEPUT-"PITESTI" şi Sfărșit="BUCURESTI") 

Partea marcată în condiție, permite definirea oricăruia din sensurile unui DRUM. 


SELECT DISTINCT DRUM, LUNGIME FROM DRUMURI WHERE 
(UPPER(INCEPUI)='BUCURESTI' AND UPPER(Sfârşit)="PITESTI) OR 
(UPPER(SfürgitT) -"BUCURESTI AND UPPER(INCEPUI)='PITESTI) 


Selecţia din Jumal a formulelor Contabile şi sumelor aferente: 


SELECT Jurnal. ComDB As [Cont Debitor], JurnalContCR As [Cont Creditor], 
Jurnal Valoare FROM Jurnal; 


Operația de joncțiune (JOIN) este una din cele mai importante operaţii ale algebrei 
Telalionale. Acesta ne permite să stabilim conexiuni între datele conținute în diverse relații, să 
Comparăm valorile conţinute în ele şi astfel să utilizăm caracteristicile fundamentale ale 
modelului reiesite din bazarea sa pe valori. 

Operajia de joncțiune este o derivație a produsului cartezian (în anumite situaţii este 
Tedundantà cu acesta). În general realizarea produsului cartezian este o operaţie laborioasă și 
Sostisitoare. Operația de joncțiune presupune utilizarea unui calificator care să permită 
Eie valorilor diferitelor (sau aceloraşi) atribute din două relaţii (sau dintr-o singură 

). 


è 
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Operația de joncțiune are sens si își găseşte o largă aplicabilitate în situaţia în 
intersecția schemelor relațiilor este diferită de zero (adică au cel puţin un atribut 
aparținând aceluiași domeniu, fără să fie obligatoriu ca denumirea acestora să fie identică), 
ce poate fi exprimat astfel: 


Ti D4 r pentru X,NX240. 


Notafiile consacrate pentru operația de joncțiune sunt: 

- rry 

- JOIN (rural): 

- rixri[6] 

unde 0 este un calificator multi-atribut care permite compararea atributelor relaţiei r, 
atributele relaţiei r». Operatorii de comparaţie atribuifi lui 0 pot fi: <, =, >, <, 2 şi 4. 

A treia notație sugerează faptul că operaţia de joncțiune este un produs cartezian asupra 
căruia se aplică o restricție 0. Reprezentarea grafică a operaţiei de joncțiune este similară celei a 
produsului cartezian. 

În general, joncţiunea combină două sau mai multe relații, nu neapărat distincte, pe 
toate atributele comune lor. Deci, se poate spune că operaţia de joncțiune a două relaţii ri şi m, 
care au câte un atribut aparținând aceluiași domeniu, produce o nouă relaţie ry ale cărei rânduri 
(tupluri) se formează prin concatenarea rândurilor (tuplurilor) celor două relații care satisfac 
restricția 6 asupra valorilor asociate atributelor ce se compară, urmată de eliminarea unuia dinte 
atributele comune. Atributele pe care se face joncțiune se numesc "atribute de joncțiune”. ^ 

În activitatea practică pot apare mai multe cazuri particulare de joncțiune: — — 


Joncțiunea naturală (natural join), notată cu simbolul b4, este joncţiunea bazată pe 
egalitatea atributelor de joncțiune ale relaţiilor implicate. Dacă relaţiile ri(X1) şi r2(X2) au egale 
atributele A;cX; şi respectiv B,e Xs atunci joncțiunea naturală este joncțiunea după calificarea 
AB, iar rezultatul joncyiunii este o relaţie r3 cu schema definită pe reuniunea mulțimilor de 
atribute ale operanzilor dar cu atributele comune luate o singură dată, adică pe mulțimea 
QGUX;-(X,nX;). Atributele comune în relaţiile operand le vom nota cu Xız si sun 
reprezentate de intersecția schemelor X, cu Xz, adică Xi (^X?) iar [Xi] Xa]. Ca 
aceste precizări joncţiunea naturală rr? a lui r(X:) cu r(X;) este o relație definită pe 
QGuX) astfel: 
rjPeri- (te(XiUX) | tier; si ter cu t[X;]-t; si t[X2]7t2) sau, mai concis 
nba (te(GUX:) | [Xen si Xen} 

Dacă pentru fiecare tuplu t; din X; există un tuplu t in Darz astfel încât t[X;]"t 
similar pentru fiecare tuplu t? din X» există un tuplu t in rybar> astfel încât t(X2]-t? vom spune 
joncţiunea este joncțiune completă (adică fiecare tuplu din operanzi contribuie la formarea 
puţin un tuplu în rezultat). 

Dacă există tupluri în r, sau rz care nu contribuie la rezultatul rjr; vom spune că 
tupluri balansate (dangling tuples) in relaţiile jonctionate. Numărul de tupluri ale joncfi 
ribar va fi cuprins între 0 şi produsul cardinalitàjilor jrbxira| relaţiilor operând cu 
precizări: 


- dacă joncflunea lui ni cu m este completă atunci marnărul său de tupluri va fi 
puţin egal cu Max(lrillr2]); 


i 
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- dacă XXX, conține o cheie a lui rz joncţiunea lui r cu ta contine cel mult |] 


- dacă XınXz este o cheie primară a lui r; atunci vom avea o restricţie referenială 
între XX în ri şi acestă cheie a lui rz iar joncțiunea contine exact [n tupluri. 


Operatorul de joncțiune naturală este: 
-  comutativ, adică rbr este întotdeauna egal cu m4r; ; 
- distributiv, adică ruDa(ezbar3)> (ribar))bary. 


Dacă X;sX» atunci rezultatul joncfiunii este definit întotdeauna pe reuniunea XX» şi 
conţine ca tupluri produsul cartezian al r; cu rz, rixr;. Acest produs cartezian poate produce 
tupluri nesemnificative în rezultat. Pentru a elimina acest inconvenient a fost introdus un 
operator de joncțiune derivat, denumit tetha-join (joncțiune teta), definit ca produs cartezian 
urmat de selecţie, astfel: r; Pr rz =OF (ribr:). Dacă condiţia F este o conjunctie de expresii 
atomice formate cu operatorul de egalitate atunci operatorul de joncțiune este denumit equi-join. 


Exemplu: Din relaţia descrisă în tabela 6.4 (MATERIALE) şi relația descrisă în tabela 
6.6 (MATERIALE CONTRACTATE) dorim să extragem cantităţile contractate din fiecare 
material astfel pentru a obține o tabelă cu schema «codi, denmat, um, pu, cant, contr 


SELECT m.codm, m.denmat, m.um, m.pu, c.cant contr 
FROM materiale m, materiale contractate c 
WHERE m.codm-c.codm; 


Considerăm relaţiile rı şi rz cu schemele X; = {A,B,C} si respectiv X3=(B,C,D). În 
urma operației de joncțiune naturală a lui r; cu rz va rezulta rs cu X;7 (A,B,C,D) redată în figura 
69. 


E 
DAXEBSEES nenn 
al | bl | cl 

a2 | b2 | c2 

[a3 | bi | e2 

ai | b2 | c3 
CERED 
[bi | cl | di 
Dei | er | a2 
[2 | e3 | 43 


Fig. 6.9. Joncjiunea naturală a lui R1 cu R2 pe coloanele B si C 


Exemplu: Se doreşte listarea tuturor drumurilor nationale pe județe, din subschema 
prezentată in figura 6.3, astfel: 


[Dine ] Aneesa [prum [va [vi [eus [ws [ rone] 


Coloanele (atributele) DIDP şi ADRESA apar în tabela (relația) DJDP (Direcţii 
Judetene de Drumuri şi Poduri) iar restul coloanelor (DRUM, KMI, MI, KMS, MS, 


122 


— — įm m~ m — 


LUNGIME) apar în tabela DNJUD (Reţea Drumuri Naţionale pe Județe). Pentru a răspunde la 
această cerere se va efectua o joncțiune naturală între tabelele DJDP şi DNJUD pe atributul 
JUD. Predicatul joncfiunii este: 
DJDP.JUD = DNJUD.JUD 


Ín si în care operatorul de comparaţie este > avem de a face cu "joncțiune mai 
mare decât...". În mod asemănător joncţiunea mai poate avea si alte denumiri în funcţie de 
operatorul de comparaţie luat în considerare. 


Autojonc[iunea relaţiei r după atributul A; este joncţiunea relaţiei r cu ea însăşi după 
predicatul AA;, ceea ce se poate exprima astfel: JOIN(r/AFA)). 


Exemplu: Se doreşte listarea drumurilor pe judeţele pe care le parcurg cu porțiunile de 
drum aferente pentru toate drumurile naţionale (subschema din figura 6.3). Tronsoanele de 
drum vor fi listate în ordinea naturală de continuitate. Pentru rezolvarea acestei cereri va fi 
implicată tabela DNJUD căreia i se va aplica o autojonctiune pe coloana DRUM. Deoarece 
operaţia de joncțiune implică două relații (tabele) la intrare vom conveni faptul cà tabelei 
implicate DNJUD i se vor atribui două supranume (alias): DNJUD alias R; și DNJUD alias Rs. 
Coloanele selectate vor fi: «JUD, DRUM, KMI, MI, KMS, MS». În acest caz predicatul va arăta 
astfel: R.DRUM = RzDRUM împreună cu relaţia de ordine dintre rândurile (tuplurile) 
rezultate: Ra.KMI Ascendent, RMI Ascendent, R KMS Ascendent, RMS Ascendent. 
Deoarece asocierea implicată în această cerere este definită recursiv (DNJUD la DNJUD prin 
DRUM) va trebui să introducem în cerere şi condiția ca rezultazul să fie format din tupluri 
distincte (DISTINCT). 


Exemplu: Dorim să obținem din relația Angajat, lista cu Nume Angajat, Prenume 
Angajat, Nume Soy(ie), Prenume Soy(ie) ceea ce implică o autojoncjiune a relației Angajat cu ca 
însăși. Relaţia Angajat este: 


52011040234 cu. [Maria 


iar cererea SQL care realizează autojoncfjunca poate aráta astfel: 

SELECT Angajat. Nume, Angajat. Prenume, Angajat_1.Nume, Angajat_1. Prenume 
FROM Angajat INNER JOIN Angajat AS Angajat. ON Angajat. CNP = Angajat_.Sot; 
iar rezultatul este: 


Claudiu Ionescu Maria 
— — María. Ionescu “Claudiu aak 

Pentru relaţia Angajat SGBD-ul utilizat a creat un alias (Angajati AS Angajati _1) pentru 
a putea utiliza numele său la calificarea atributelor (de joncțiune, de regulă, dar nu are 
importanță dacă se califică şi alte tipuri). 


Joncțiune externă (outer join). În rezultatul tipurilor de joncțiune prezentate până acum 
apăreau numai rândurile care sc obțineau din joncţiunea rândurilor celor două relaţii operand 
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EE... joncțiune). Rândurile dintr-o relație operand fără corespondent în cealaltă 


operand nu apăreau în rezultatul joncjiunii. Există totuşi numeroase cazuri în care este 

"util să apară în rezultatul jonctiunii şi astfel de rânduri dintr-o relație operand fără corespondent 
de joncțiune în cealaltă relație Joncţiunea care oferă această posibilitate a fost numită 
joncțiunea extemă [DATE86). Operatorul de joncțiune externă are trei variante. Pentru definirea 
acestor variante vom considera două relaţii r, şi r; pe care se aplică operandul de joncțiune. 


şefia] 
[Adam — | 


Cu aceste precizări operatorul de joncțiune externă este definit astfel: 
* n Pág ry care include în rezultat toate tuplurile din relaţia rj şi numai acele tupluri din rz 
care au corespondent în rj, conform modului ilustrat în relația: 


* T D&aiGuT ra care include în rezultat toate tuplurile din relaţia ra şi numai acele tupluri din ri 
care au corespondent în r;, conform modului ilustrat în relația: 


* M 54ruu ra care include în rezultat toate tuplurile din relaţia r, şi rz care au corespondent şi 
tuplurile din ambele care nu au corespondent, conform modului ilustrat în relația: 


Exemplu: În rezultatul (obţinut prin joncțiune) care oferă date despre clienții si 

comandate de aceştia se doreşte să apară şi date despre produsele fabricate dar care 

M au fost încă solicitate de nici un client. Produsul fabricat dar necomercializat încă nu are 
Sorespondent în relaţia beneficiari. Fie relaţiile BENEFICIARI şi PRODUSE din figura 6.10. 
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BENEFICIARI 
[COD | DENUMIRE | " ADRESA | COD PRODUS] 
| 101 | CESTRIN | SOVEJA 115 | ' 40542] 
| 102 [Ase CSIE_| DOROBANTI | 40521 | 


PRODUSE 


40542 486DX2 
[ 41736 | Statie lucru IBM Compatibil | 


Fig. 6.10. Relaţiile BENEFICIARI si PRODUSE 


Rezultatul solicitat mai sus se obține prin joncţiunea externă a celor două relaţii pe? 
atributul COD-PRODUS şi arată astfel: 


COD DENUMIRE: ADRESĂ = COD PRODUS  DENP CARACTERISTICI 


d cesor- 66 MHz 
5 AT4B6;DX2 - 66 MHz; 4 Mb 
“Staţie lucru IBM compatibil 


Se observă faptul că pentru produsul "Staţie lucru” nu există în răspuns valori în 
coloanele corespunzătoare relaţiei BENEFICIARI. 3 
Obţinerea liniilor necesare pentru balanța curentă utilizează subschema bazei de date 
ilustrată în figura 6.11 pentru care condiția de joncțiune specifică includerea în rezultat a tuturor - 
rândurilor din Balanta şi numai a acelor rânduri din tabela Plan de Conturi pentru care valoarea . 
din coloana Simbol este egală cu o valoare Simbol din Balanta. 


aveul etii ari ct 


Fig. 6.11. Subschema pentru operația de evaluare a 
balanței 
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Fraza SQL. care realizează joncţiunea este: 

SELECT DISTINCT Balanta [An Balanta], Balanta. [Luna Balanta). Balanta. Simbol, 
Plan, de Conturi.Descriere, Plan de Conturi. DescrExt, Format(Balanta [Dblan], 

00") AS Dblan, Format(Balanta.[CrlIan], "#,#00.00") AS Crlan, 
Format(Balanta.[DbPrec],"$,800.00") AS DbPrec, Format(Balanta.[CrPrec], "&,400.00") AS 
CrPrec, Balanta. DbLuna, Balanta.CrLuna, (Balanta Dblan+ Balanta.DbPrec-- 

Balanta. DbLuna) AS DbTotal, (Balanta. Crlan+ Balanta. CrPrec + Balanta.CrLuna) AS 
CrTotal, (1If((Balanta. Dblan+ Balanta. DbPrec+ Balanta. DbLuna)> Balanta. Crlan+ 
Balanta. CrPrec+ Balanta. CrLuna), (Balanta Dblan+ Balanta. DbPrec+ Balanta. DbLuna)- 
(Balanta.Crlan+ Balanta.CrPrec* Balanta.CrLuna),0)) AS SoldDB, (Ilf((Balanta.Dblan-- 
Balanta. DbPrec+ Balanta. DbLuna)« (Balanta.CrIan* Balanta CrPrec+ Balanta.CrLuna), 
(Balanta. Crlan+ Balanta. CrPrec+ Balanta. CrLuna)-(Balanta. Dblan+ Balanta. DbPrec+ 
Balanta. DbLuna),0)) AS SoldCR 

FROM Plan_de_Conturi 

RIGHT JOIN Balanta ON Plan de Conturi.Simbol = Balanta. Simbol 

ORDER BY Balanta. Simbol; 


Fig. 6.12. Subschema utilizată la calculul balanței 


În această subschemă tabelele TotalCR și TotalDB sunt cereri formulate ca în figura 6.13 
iar Balanta si Plan. de. Conturi sunt tabele de bază ale bazei de date financiar-contabile. 


[SELECT Balanta.Sinibol, SumCurnal.Valoare) AS Crluna T T 
FROM Balanta, Jurnal ; 
WHERE (Jurnal. ContCR) Like (Trim([Balanta] [Simbol]) & "*") 
GROUP BY Balanta Simbol; -` Pnl n 


SELECT Balanta Simbol, Sum(Jurnal. Valoare) AS CrLuna 
FROM Balanta, Jurnal 
WHERE ((Jurnal.ContCR) Like (Trim([Balanta].[Simbol]) & "*") 
.: GROUP. BY Balanta. Simbol; cro 


13. Cererile TotalCR si TotalDB. 


SELECT DISTINCT Balanta [An Balanta], Balanta [Luna Balanta], Balanta Simbol, 
Plan_de_Conturi. Descriere, Plan de Conturi.DescrExt, Format(Balanta. Dblan, "#,#00.00") 
AS Dblan, Format(Balanta. CrIan, "#,#00.00") ") AS Crlan, Format(Balanta. DbPrec, 
"4,400.00") AS DbPrec, Format(Balanta.CrPrec, "#,#00.00") AS CrPrec, TotalDB.DbLuna, 
TotalCR.CrLuna, (Balanta. Dblan+ Balanta.DbPrec-- Balanta. DbLuna) AS DbTotal, 
(Balanta.Crlan+ Balanta.CrPrec+ Balanta.CrLuna) AS CrTotal, (Ilf((Balanta.Dblan-- 
Balanta.DbPrec* Balanta. DbLuna)> 

(Balanta. Crlan+ Balanta. CrPrec--Balanta. CrLuna), (Balanta. Dblan+ Balanta. DbPrec+ Balan 
ta. DBLuna)-(Balanta. Cr lan+ Balanta. CrPrec+ Balanta. CrLuna),0)) AS SoldDB, 
(If((Balanta.Dblan* Balanta. DbPrec+ Balanta DbLuna) (Balanta. Crlan+ 

Balanta. CrPrec+ Balanta. CrLuna), (Balanta. Crlan+ Balanta. Cr Prec + Balanta. CrLuna)- 
(Balanta. Dblan+ Balanta. DbPrec+ Balanta. DbLuna),0)) AS SoldCR 

FROM ((Plan de Conturi RIGHT JOIN Balanta ON Plan de Conturi.Simbol = 

Balanta. Simbol) LEFT JOIN TotalCR ON Balanta.Simbol = TotalCR.Simbol) LEFT JOIN 
TotalDB ON Balanta. Simbol = TotalDB.Simbol 

ORDER BY Balanta. Simbol; 


Operaia de împărţire realizează împărțirea unei relaţii deîmpărțit rı, de grad m+n, la o 
relație împărțitor r», de grad n si produce o relație rezultat de grad m. Atributele mi ale lui ri şi 
atributele i ale lui r2, pentru /« 7j n, trebuie să fie definite pe aceleaşi domenii. Să considerăm 
primele m atribute ale lui r; ca un atribut compus X, şi ultimele n ca un alt atribut compus Y. 
Rezultă că relația r; poate fi gândită ca o mulţime de perechi de valori <x,y>. Similar relaţia r 
poate fi gândită ca o mulțime de valori <y>. Rezultatul împărțirii lui rı prin rz îl reprezintă 
mulţimea valorilor <x> pentru care perechea <x,y> apare în r; pentru toate valorile <y> care apar 
în ra. Atributele rezultatului au aceleaşi denumiri ca primele m atribute ale relaţiei ri. 


Notafiile consacrate pentru operaţia de împărțire sunt: 
- reri 


- DIVISION (rur) 


În figura 6.14 a) si b) este redată reprezentarea grafică a operaţiei de îinpărțire. În plus 
figura 14 b) oferă un exemplu de aplicare. 


IVIDE———*| 
s nre 
CHR] E H 
R Farm 
laiz] n 
[5 [x | 
Ledy] 
a) n b) 


Fig. 6.14. Diviziunea relațiilor 
În figura 6.14 b) din relația rı se ia fiecare valoare distinctă, pe care o vom denumi 4, 2 
primei coloane si se constituie mulțimea de valori formată din valorile asociate din cea de a dova 
coloană. Dacă această mulțime formată este egală sau include mulțimea valorilor din relația 12 
atunci valoarea q la care s-a asociat apare în rezultat. Operația de împărțire trebuie să respecte 
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pluri din relația deimpáriit ri, adică raxrzCri. 
3 
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63. Construirea expresiilor in algebra relaţională 


A... Algebra relațională este un limbaj procedural bazat pe concepte algebrice care constă 
intr-o colecţie de operatori definiti pe relaţii şi care produce ca rezultat relaţii. Proceduralitatea 
sa este dată de faptul că atunci când scriem expresii ale algebrei relaționale nu facem altceva 
decât să dăm o secvenţă de operaţii care vor genera răspunsul cererii noastre. O expresie generală 
în algebra relaţională este construită din subexpresii. Dacă Ej si Ez sunt expresii ale algebrei 
relationale atunci expresiile: 

- ENEz ErEy EXE, 

- Gp(E,), unde P este un predicat pe Ej; 

- Tis (Ej), unde S este o listă constând din unele atribute din E, 


sunt expresii ale algebrei relaţionale si formează operațiile fundamentale ale algebrei 
relationale, Ele sunt suficiente pentru a exprima orice cerere a algebrei relajionale. 


Pentru exemplificări considerăm baza de date Personal cu schema: 


Ángajat(CNP, Nume, Vârsta, Salariu, Cod. Loc) si Loc_de_Muncă(Cod, Denumire, Șef) 
cu extensiile relaţiilor prezentate în figura 6.15. 


Coloanelor Cod_Loc din Angajat şi Cod din Loc_de_Muncă li s-au dat dd diferite 
pentru a nu mai fi necesară calificarea în exemplificări. În situaţii reale este preferabilă 
utilizarea aceleiaşi denumiri pentru coloanele de joncțiune, 
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Exemple: m 

-intersecția relaţiilor r cu m poate fi înlocuită cu operaţii de diferență astfel: 
non=- (ri -t)i , 

= oneties cu predicat (theta-join) a relațiilor r; cu ra după predicatul 0 poate fi înlocuită cu 
o selecție, astfel: ribder2 =Oe(riXr2); 


1 
j 


- joncțiunea naturală a relațiilor (X1) şi (X3), n bx, este o relaţie pe schema X+UX2 si este 
proiecția pe XiUX a unei joncțiuni cu predicat care necesită expresii de forma ry.A=r2.A 
pentru fiecare atribut A eX, ^X». Dacă Xy X27 (A143... As) atunci : 
noan Slava, Ui Pe non a nas 35 P 

-' diviziunea a două relaţii, rı(Xı) si r:(X2), cu XıcXz este o relație pe schema Xı-X2. Un tuplu 
t aparține relației rı+rz dacă pentru fiecare tuplu t; din r există un tuplu t; în r; care satisface 
următoarele două condiții: t;[X;]"t;[X2] si [X-X] X1-X). 


Operația de împărțire poate fi exprimată în termenii celor cinci operaţii fundamentale astfel: 
nn m ao, (6) TE e (r-r 0) x) 77)- 


6.4. Echivalenta expresiilor în algebra relationalá 


Ca orice limbaj formal algebra relationalà permite formularea expresiilor echivalente, 
Vom nota echivalenţa prin =. Vom defini echivalenja referindu-ne la expresiile definite pe 
schemele bazelor de date. Două expresii pe o schemă de bază de date, E; si Ez, sunt echivalente, - 
adică ErapE> dacă Ej(r)" Exft) pentru fiecare instanţă r a relaţiei R. Două expresii pe o schemă _ 
de bază de date, Ey şi Ez, sunt absolut echivalente, adică Ej&E; dacă EjsgE? pentru fiecare | 
schemă de relaţie R. a -oa 

Echivalenfa expresiilor în algebra relationalà este extrem de importantă la optimizarea | 
cererilor exprimate in SQL prin aceea că ele sunt translatate în expresii ale algebrei relaționale, 7 
expresii pentru care se evaluează costul satisfacerii cererii (cost exprimat în termenii 
dimensiunii rezultatelor intermediare şi finale). Dacă există mai multe expresii diferite, 
echivalente cererii atunci se va alegea acea expresie care costă cel mai puțin. Pentru a obține - 
expresiile echivalente se utilizează transformări echivalente, adică operaţii prin care se 
substituie o expresie echivalentă cu o alta. 

Forma generală a frazei SQL: 


Select A143... An From rura... rm [Where P] în care: 

- ArAnA reprezintă atributele care dorim să apară în rezultat; 

- FF d.Pm reprezintă relaţiile implicate; 

- P este predicatul sau condiţia pe care trebuie să o îndeplinească tuplurile care vor 
contribui la calculul rezultatului; 


este echivalentă cu următoarea expresie a algebrei relationale: 
TL,, 4 (on x x x7.) 


Dacă clauza Where ... lipseşte (posibilitate indicată prin [...]) atunci predicatul P 
considerat Adevărat. 


În cele ce urmează vom prezenta câteva exemple de transformări echivalente: 

- - Atomizarea selecfiilor: o selecţie construită pe baza unui predicat conjunctiv poate fi 
substituită cu o cascadă de selecții: o,» (E) a, (c, (E)), unde E este orice 
expresie. Conform modului de definire această transformare permite aplicarea 
transformărilor subsecvente care operează pe selecţii cu condiții atomice; 


- . Proiecţii în cascadă: o proiecţie poate fi transformată într-o cascadă de proiecții care 
"elimina" atribute în diverse faze: TI, (E) m IL, (TL, (E)) dacă E este definită pe o 
muljime de atribute în care sunt incluse atributele X şi Y; 


-  Amticiparea selecției cu respectarea joncfiunii: a (E, >< E.) = E, >40 (E;) dacă 
expresia referă numai atribute din expresia Ez; 


- Anticiparea proiecției cu respectarea joncfiunii: 


Fie expresiile E, şi E definite pe X; si respectiv, Xz. Dacă YcX, si Yc X; Xo (adică 
atributele X; - Yz nu sunt implicate în joncțiune) atunci are loc echivalenja: 
IL, (E, >< E) = E, >< Tlp, (E). 


Combinând această expresie cu proiecția în cascadă obţinem următoarea expresie 
echivalentă: TI, (E, ><; E) = H(Il (E), I1, (E,). Vom desemna prin X, si X; 
atributele lui Ej, respectiv, Ez si cu J; si Jz submullimea de atribute care apar in condiţia F. În 
aceste condiții vom defini pe Y; si Ya astfel: 

YADI, 

Yan 

Pe baza acestei echivalenje putem să eliminăm din fiecare relație toate atributele care nu 

apar în rezultatul final si nu sunt implicate în joncțiune. 


- Combinarea selecției si produsului cartezian pentru a forma un tetha-join: 
c, (E, >< E.) « E, P4, E, 


- Distibutivitatea selecţiei faţă de reuniune: 
9, (E, vE)ao(E)vor(E) 


~ Distributivitatea selecției faţă de diferenţă: 
9, (5, - Ej) =0;(E,)-0;(E,) 


-  Distributivitatea proiecției faţă de reuniune: 
T(E, VE) e TL (E) UTI, E.) 


. Similar acestor transformări condițiile (predicatele) compuse pot fi transformate în 
condiţii atomice conform exemplelor următoare: 


O selecţie pe predicatul FivF; pe relația R este echivalentă cu o reuniune de selecţii pe F; si 
respectiv Fz pe relaţia R:0 pup, (R) «a, (R)ua; (R); 


— áo TL E em 


Exemplu: Pe relaţia Angajat cu extensia prezentată în figura 6.25 se doreşte lista cu CNP, 
Nume, Vârsta care au fie salariu mai mare de 25 milioane fie locul de muncă 101. Acestă cerere 
poate fi exprimată în SQL ca: 

- selecţie cu expresie predicativă formată cu conectiva Or 

SELECT Angajat. CNP. Angajat. Nume, Angajat Vârsta 
FROM. 
WHERE (([Angajat)![Salariu]>20 Or [Angajat]![Cod_Loc]=101)); 

- ca reuniune de selecții 

SELECT Angajat. CNP, Angajat. Nume, Angajat. Vârsta 
FROM Angajat 

WHERE (([Angajat)![Salartu]>20)) 

UNION 

SELECT Angajat. CNP, Angajat. Nume, Angajat. Vârsta 
FROM Angajat 

WHERE (([Angajat]![Cod_Loc]=101)); 


ambele exprimări producând același rezultat: 
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O selecție pe predicatul Fj^F; pe relaţia R este echivalentă cu o intersecție de selecţii pe Fi și 
respectiv F; pe relaţia R: op „y, (R) ma, (Ryo, (R); 


O selecție pe predicatul FF; pe relația R este echivalentă cu o diferență de selecții pe Fi sí 
respectiv Fz pe relația R: op p (R) wa, (R) - as, (R). 

Exemplu: Considerăm schema bazei de date : 

Angajat(CNP, Nume, Vârsta, Salariu, Cod Loc) şi Loc_de_Muncă(Cod. Denumire. Şef) 


cu extensiile relaţiilor din figura 6.15. 

Dorim să obținem lista CNP, Nume, Vârsta cu angajaţii care au salariul mai mare de 25 
milioane, Acestă cerere este formulată în termenii algebrei relajionale ca o proiecţie pe CNP. 
„Nume, Vârsta din selecţia din relaţia Angajat după predicatul Salariu>25, adică Tonene vase 
(Osutru25(Angajar)), exprimată în SQL astfel: 

SELECT Angajat. CNP, Angajat. Nume, Angajat. Vârsta FROM Angajat 

WHERE ((([Angajat)![Salariu])>25)); 


şi produce ieşirea: 
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Hi Tone Deramsre (Loc de. Muncibdcut 1e-cod (Osurao2s( Angajat); 
L Cererea SQL poate fi formulată astfel: 
$ 


T> SELECT Angajat. Nume, Loc_de_Muncă Denumire FROM Loc_de_Muncă 
Ta, INNER JOIN Angajat ON Loc de Munci Cod = Angajat. Cod Loc 
E WHERE ((([Angaja)!(Satariu])>23); 


Termenul calcul fona so refert la o familie de limbaje de interogare (cereri) bazate 
pe calculul de ordinul întâi. Faţă de algebra relaționalā care este un limbaj 
procedural limbajele bazate pe calculul relajional sunt declarative adică specificarea cererii este 
efectuată în termenii proprietăţilor rezultatului. Există o multitudine de versiuni ale calculului 


corespund 
Pentru a efectua o comparaţie între calculul relational si algebra relațională vom defini, în 
jo pn mee node deedee de domini ai nohe d at, 

O expresie a unui limbaj de cereri (interogare) este independentă de domeniu dacă 
rezultatul său, pe orice instanță corectă a bazei de date, nu sc schimbă dacă schimbăm domeniile 
pe baza cărora este evaluată expresia. Un limbaj este independent de domeniu dacă toate 
expresiile sale sunt independente de domeniu. Cu aceste precizări algebra relajionalà este un 
limbaj independent de domeniu în timp ce calculul relaional nu este. 

Două limbaje de cereri sunt echivalente atunci când pentru orice expresie în unul din ele 

E o amonia Ojai CABA olor e CR ei bei e Hd 
şi calculul relațional pe domeniu nu sunt echivalente deoarece prima este 
eredi o — eren dmat n eee m e 


k 
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Algebra relationalà şi calculul relational 


6.5.1. Calculul relational orientat pe domeniu 


Expresiile calculului relaţional orientat pe domeniu au forma {4;:x, 
-— 41... Ás Sunt atribute distincte care nu trebuie să apară în neapărat i 
date pe care se defineşte interogarea (pot fi constante, apeluri de funcţii etc.); 
Xp... Xy Sunt variabile; 
feste o formulă care respectă următoarele reguli: 
* este de una din următoarele forme atomice: 

. : Ap) este o schemă relațională și x;....x, sunt 


i 


*oxÓy sau xf, cu x şi y variabile iar c constantă şi 0 un operator de comparare (=, <, 
225,0) 

* dacă fi si f; atunci fj/f, fjv si fi sunt formule; 

o dacă f este o formulă şi x o variabilă atunci 3x( si Vx) sunt formule (3: există - 

EXISTS si V: oricare ar fi - ANY). d 


Sij itte ros ct (eta 


Aux este denumită "listă țintă” deoarece defineşte structura | 
pe 4... s care conține tupluri ale căror valori substituite pentru. 
xi, X, evaluează formula la Adevărat. t 


Evaluarea formulei la Adevărat urmează regulile: 1 

=. formulă atomică A(4y3x;... Ax) este evaluată la Adevărat pentru valorile xj... x 

care formează un tuplu în R; : 

- formulă atomică x0y sau x6c este evaluată la adevărat dacă x este in relația 0 cu y," 

respectiv c; 

- conectivele av şi — au înțelesul general de operatori logici şi se evaluează în 
conformitate cu acest înţeles; 

- o formulă construită cu cuantificatorii: 

* Zw) este Adevărată dacă există cel puțin o valoare pentru x care o face. 

adevărată pe f; ^ “| 

e Vx(f) este Adevărată dacă feste adevărată pentru orice valoare a lui x. 


Exemplu: Considerăm schema din figura 625: Angajat(CNP, Nume; Vârsta, Salariu | 
Cod Loc) şi Loc de Muncă(Cod Loc, Denumire, Şef) si dorim să obținem lista cu angajaţi. 
care au salariul mai mare de 25 milioane. Acestă cerere este formulată în termenii algebrei. 
relationale ca o selecție din relația Angajat după predicatul Salariu>25, adică as. ;s(Angajat) 
Acestă expresie poate fi formulată în termenii calculului relafional astfel: 


ÍCNP:m, Nume:n, Vársta:, Salariu:s, Cod Loci | Angaja(CNP:m, Nume:n, Vârsta, 
Salariu:s, Cod Loc:l) A5>25 


În acestă exprimare condiţia: 
-  Angajat(CNP:m, Nume:n, Vársta:v, Salariu:s, Cod Loc:l) specifică faptul că valorile 
m,n,v,s,l trebuie să fie tuplu în relaţia Angajat; 
- 5225 specifică faptul că în răspuns vor fi incluse numai acele tupluri pentru cart 
valoarea variabilei s este mai mare ca 25. 


Dacă vom considera numai partea de calcul relational în care expresiile 
independente de domeniu vom avea următoarele echivalenfe cu algebra relațională: 


- pentru fiecare expresie a calculului relajional care este independentă de domeniu 

există o expresie a algebrei relaționale echivalentă acesteia; 

- pentru fiecare expresie a algebrei relafionale există o expresie a calculului relational 
echivalentă acesteia. 


SGBD-urile actuale implementează un limbaj uzual bazat în parte pe calculul relaional 
orientat pe domeniu cunoscut sub numele de QBE (Query. by. Example). Acesta utilizează o 
imerfaţă grafică cu utilizatorul prin care acesta este eliberat de sarcina specificării detaliilor. 
Pentru cererile exprimate în QBE există posibilitatea vizualizării automate a expresiilor 
echivalente exprimate în algebra relationalà (sub formă de fraze SQL). 


6.5.2. Calculul relational orientat pe tuplu cu declararea rangului 
(intervalelor de variaţie a) variabilelor libere 


O expresie în calculul relational orientat pe tuplu cu declararea rangului variabilelor 
libere are forma generală: (T | L |f ), unde 
~ Leste lista rangului (intervalelor) care enumereazá variabilele libere ale formulei f cu 
intervalul respectiv de variaţie. Z este o listă de tipul x(R), cu x o variabilă si R o 
denumire de relație; dacă x(R) este în lista rangului atunci în momentul evaluării 
expresiei valorile posibile ale lui x sunt exact tupluri din relaţia R; 
- Teste lista țintă compusă din elemente de tipul Y-x.Z (sau mai simplu, prin reducere, 
de tip x.Z), unde x este variabilă iar Y şi Z sunt secvențe de atribute (de lungime 
egală); atributele din Z trebuie să apară în schema relaţiei care determină rangul lui x. 
În cazul în care rangul lui x este relația pe atributele X atunci XX | poate fi abreviat 
cu x.* si putem să-] scriem în expresii ca atare; 
- feste o formulă cu: 
* atomi de tipul x 40c sau xz. 4/0; 4? care compară, în concordanță, valorile lui x 
pe atributul A cu constanta c si valorile lui x pe atributul 4; cu valorile lui x; pe 
atributul 45; 
*  conective de tip logic a,v si =; 
e cuantificatori, care asociază rangul variabilelor, respectiv: 
= 2x(R)() care înseamnă "există un tuplu x în relația R care satisface formula f"; 
= Vx(R)(f) care înseamnă "fiecare tuplu x din A satisface formula f^. 


Declarările de ranguri în lista de ranguri şi cuantificări au un rol important: la 
introducerea unei variabile x o declaraţie de rang R(x) specifică faptul că x poate să ia valori 
Numai dintre tuplurile relației R cu care este asociată. Din acest motiv acest limbaj nu necesită 


condiții atomice ca cele cerute de calculul relational orientat pe domeniu. 


Exemplu: Considerăm schema bazei de date: Anga/at(CNP, Nume, Vârsta, Salariu, 


Cod Loc) si Loc de Munca(Cod, Denumire, Şef) cu extensiile relaţiilor din figura 6.15. Lista 
angajaților care au salariul mai mare de 25 milioane se exprimă astfel: 
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Exemplu: Lista angajaţilor cu structura CNP, Nume, Vârsta pentru angajaţii cu salariul 
mai mare de 25 milioane se obține printr-o expresie de forma: 
{a (CNP, Nume, Vârsta) | a(4ngajat) | a.Salariu» 25 ) 


Exemplu: Lista cu numele angajaţilor care au salariul mai mare de 25 milioane și 
denumirea locului de muncă se obţine printr-o definiţie de forma: 
fa. Nume, LDenunire | a(Angajat), KLoc_de_Muncă) | a. Cod_Loc=l Codna-Salariu>25 } 


7.1. Conceptul de BDOO 
Deşi exprimarea pare uşoară dezavantajul calculului relaţional orientat pe tuplu c: 
declararea rangului nu permite exprimarea oricărei cereri (în particular nu permite, de exemplu. Pentru definirea unci BDOO vom pleca tot de la definirea unei baze de date la modul 
exprimarea operatorului de reuniune) aşa cum o permite algebra relațională (sau calculul general, şi anume: 


relational orientat pe domeniu. 
Implementarea practică a calculului orientat pe tuplu este efectuată în SGBD-urile 
actuale în două moduri: $ 
- prin acces la cereri SQL din limbaje procedurale pentru prelucrări tipice în care prin SQL 
se obține o relație pe care se efectuează prelucrările dorite, la modul tuplu cu tuplu, prin 
instrucțiunile procedurale ale limbajului gazdă; 
- prin definirea de cursori si a unor instrucțiuni, pe aceşti cursori, care permit accesul și 
prelucrarea tuplu cu tuplu (metodă implementată, de exemplu, în Oracle prin PL/SQL). 


O bază de date orientată obiect este formată dintr-una sau mai multe clase de 
obiecte cu asocierile dintre acestea. 
Ca şi în alte tipuri de baze de date, o BDOO dispune de o schemă si instanțe ale 
acesteia. 
Schema BDOO conţine specificațiile fiecărei clase de obiecte ce pot fi stocate în baza 
de date. Pentru fiecare clasă C, aceasta include: 
~ tipul asociat clasei C. Acest tip determină structura fiecărui obiect al clasei C; 
- semnătura metodelor din cadrul clasei C, care precizează denumirea metodei, 
tipul si ordinea argumentelor permise metodei si tipul rezultatului oferit de acea 
metodă; 


-relațiile subclaselor care permit identificarea superclasei a lui C; 
- restricțiile de integritate si restricţiile referenfiale, sau mai mult afirmaţii generale 
care sunt similare constrângerilor din modelul bazelor de date relafionale. 
O instanţă a unei BDOO este un set de obiecte pentru multitudinea claselor 
specificate în cadrul schemei bazei de date. 


72. Premisele BDOO 


Utilizarea conceptului de obiect in informatică datează din jurul anilor 1960, când au 
| fost elaborate primele Limbaje de programare orientate obiect, dintre care amintim: Simula, 
| EIFFEL, SmaliTalk, Ada, C, C++, Common LISP, CLOS, OPAL, O;C, O2SQL, O;API, 
SQL, ACTOR, Object Pascal etc. 
De remarcat, faptul că aceste limbaje de programare nu şi-au găsit o largă utilizare 
Pentru aplicaţii ce lucrează cu volume mari de date datorită faptului că încă nu existau 
metode corespunzătoare de organizare a datelor. O astfel de problemă a fost rezolvată în 
jurul anilor 1980 când au apărut primele sisteme de gestiune a bazelor de date orientate 
` obiect (SGBDOO) cum ar fi: ONTOS, ObjectStore, Oz, GemStore, ORION, ITASCA, 
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Objectivity/DB, VERSANT, POET etc. Nici în astfel de împrejurări, abordarea obiectuală 
sistemelor de gestiune a bazelor de date nu şi-au găsit o utilizare extinsă pentru aplicaţi 
complexe sau pentru cele ce implicau volume mari de date. Acest lucru s-a datorat faptului 
că încă nu existau "Metode, tehnici şi metodologii de analiză şi proiectare orientate obiect a 
sistemelor informatice”. Acestea au apărut în jurul anilor 1990 şi dintre ele enumerăm: 

- Object Oriented Design (OOD), elaborată de Grady Booch care este o — 
metodologie similară metodologiei OMT, dezvoltă aceeaşi idee — analiza si 
proiectare iterativă insistând asupra părții de proiectare [4,6,31]; 

- Object Oriented Analysis (OOA) elaborată de Peter Coad si Edward Yourdon; 

- Object Oriented Structured Design (OOSD) elaborată de Wasserman; 

- Object Oriented System Analysis (OOSA) este o metodologie de proiectare a. 
sistemelor în timp real propusă de Sally Shaler si Steven Mellor. Autorii au 
continuat să îmbunătăţească această metodologie, publicând chiar şi o lucrare 
despre cum se pot utiliza notaţiile UML în cadrul metodologiei Shaler/Mellor; 

- Responsability Driven Design (RDD), aparținând lui Wirfs - Brock, Wilkesson si 
Wienner; 

- Object Oriented Role Analysis, Synthesis and Structuring aparținând lui Reens 
Kaugh; 

- Object Oriented Systems Analysis (OOSA) aparţinând lui Embley; 

~ Object Modeling Techinque (OMT) elaborată de James Rumbaugh, Michael - 
Blaha si alţii. Metodologia a fost iniţial utilizată de General Electric and 
Development Center; f 

- Object Oriented Software Engineering (OOSE) concepută de Ivar Jacobson. 

În plus, multe organizaţii și-au dezvoltat propria metodologie -internă, utilizând Ú 

diagrame si tehnici din diverse surse. Exemple de astfel de metodologii sunt Catalyst creată 
de Computer Sciences Corporation (CSC) şi Worldwide Solution Design and Delivery : 
Method (WSDDM), creată de IBM. Aceste metodologii diferă, dar in general combină 
analiza fluxurilor, identificarea cerințelor, modelarea proceselor de afaceri şi modelarea 
obiectuală utilizând diverse notații (OMT, Booch etc.) şi uneori includ tehnici adiţionale 
specifice modelării orientate obiect, cum ar fi fişele CRC sau cazurile de utilizare. 

Toate aceste metodologii prezentau o serie de limite precum şi multiple diferențieri - 

de simboluri, notații sau tipuri de diagrame. Aceste aspecte generau dificultăţi în privința 
înțelegerii, preluării si folosirii lor de diferite grupuri de utilizatori, în crearea de noi sisteme 
sau în procesul de mentenanţă a sistemelor. Mare parte dintre aceste deosebiri au fost 
înlăturate în 1997 prin elaborarea unui standard cu privire la simboluri, notații, tipuri de 
diagrame, tipuri de modele etc., numit UML (Unified Modeling Language). 

Majoritatea corporațiilor au adoptat UML ca notații pentru propria lor metodologie. 

Unii utilizează doar un subset al UML-ului pentru a modela ceea ce îi interesează, de 
exemplu, doar diagrama claselor sau doar cazurile de utilizare. Alţii au preluat întreg setul 
UML, utilizând inclusiv diagramele de stare şi de activitate pentru a modela sisteme în timp 
real şi diagrama de implementare pentru a modela sisteme distribuite. 

Dintre premisele ce au dus la abordarea obiectuală, în general, a analizei şi proiectării 

sistemelor informatice şi în special, a bazelor de date orientate obiect, enumerăm: 

- limitele abordării structurate în analiza şi proiectarea sistemelor informatice 
(bazele de date făcând parte dintr-o disciplină mai largă şi anume sisteme 
informatice); 

- limitele modelului relational de organizare a datelor; 

- schimbările în ceea ce priveşte orientarea aplicaţiilor ce puneau accent pe] 
stocarea datelor, către aplicaţii care pun accent pe prelucrarea mai eficientă a 
datelor cu algoritmi mai performanfi; 
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- succesele dobândite de către sistemele expert sub aspectul stocării cunoștințelor; 

- progresele dobândite în domeniul instrumentelor de tip CASE; 

- multiplele avantaje oferite de limbajele de programare orientate obiect, dintre 
care precizăm: facilităţile de refolosire a codului, modularitate crescută şi 
extensibilitate sporită; 

- apariţia unor noi tipuri de aplicaţii, cu cerinţe şi particularităţi specifice, pentru 
care sistemele de gestiune a bazelor de date relaţionale (SGBDR) s-au dovedit 
inadecvate. Dintre acestea enumerăm: proiectarea asistată de calculator (CAD - 
Computer Aided Design), aplicaţii din domeniul meteorologiei, sisteme 
informaţionale geografice (GIS — Geographic Information Systems), ingineria 
programării asistate de calculator (CASE — Computer Aided Software 
Engineering), sisteme informaţionale de birou (OIS — Office Information 
Systems), aplicaţii multimedia în cinematografie și televiziune, extinderea 
aplicaţiilor informaticii în domeniul medicinii, cercetării ştiinţifice etc. Toate 
aceste tipuri de aplicaţii presupun preluări, stocări, regăsiri si prelucrări de 
evenimente, tranzifii, stări, imagine/poză, voce/sunet, culoare, animaţie etc., care 
Ia rândul lor presupun utilizarea şi manipularea unor noi tipuri de date pe lângă 
cele tradiţionale (primitive), dintre care amintir 
~ tipuri de date abstracte (ADT,) definite de utilizator, 

- tipuri structurate, 
ipuri de obiecte mari (LOB — Large Object) cu cele două variante numite 
BLOB (Binary Large Object) şi respectiv CLOB (Character Large Object). 
Astfel de noi tipuri de date pot fi regăsite și tratate în cadrul acestui capitol şi chiar în 
următoarele capitole. : 


7.3. Avantajele si dezavantajele BDOO 


Ca orice alt mod de organizare a datelor si BDOO prezintă avantaje și dezavantaje. În 
cele ce urmează vom recurge la evidențierea celor două aspecte: 


n Avantajele BDOO. Într-o formă sintetică, avantajele BDOO ar putea fi enunțate 
fel: 
~ Oferă facilități cu privire la extensibilitatea bazei de date. Extensibilitatea apare 
ca un avantaj cheie a BDOO deoarece tipurile de date pot fi extinse folosind 
proprietatea de moştenire. Se pot adăuga noi subtipuri fără a fi necesară 
restructurarea porjiunilor existente ale bazei de date. Aşa după cum s-a mai arătat, 
în acest mod activitatea de programare se transformă într-o activitate de 
programare doar a diferențelor, sporind productivitatea muncii. Se are în atenție 
valorificarea proprietăţii de moştenire prin definirea, sau prin generalizarea, de 
superclase de obiecte cu includerea în aceasta a tot ceea ce este comun, iar apoi 
partajarea acestora în subclase de obiecte în care vor fi precizate doar elementele 
prin care se diferențiază fiecare subclasă de celelalte subclase de obiecte. Efectele 
benefice rezultate dintr-o astfel de abordare constau în reutilizarea codului, 
reducerea redundanţei datelor din baza de date, întreţinerea facilă a bazei de date, 
uşurinţă în dezvoltarea şi implementarea de noi aplicaţii etc. 
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asigura diferite mecanisme de stocare pentru diferite tipuri de date. Drept urmare 
ele s-au dovedit foarte eficiente atât pentru aplicaţii multimedia cât şi CAD. 
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Reflectă mai bine realitățile din mediul înconjurător. Lumea reală mu este 
formată dintr-o colecţie de tabele, ci un model a lumii reale apare ca o ierarhie de 
ansambluri concretizate în articole de prelucrat. Aici o parte e descompusă în 
părțile ei constituente ca subpări, care la rândul lor sunt descompuse in alte 
subpărți mai mici. Astfel de structuri sunt greu de reprezentat şi manipulat 
utilizând tabele. De fapt prin folosirea unui SQL standard, toate subpărțile unei 
părți date nu pot fi determinate tipic cu o singură instrucțiune de cereri. În 
contrast, o bază de date orientată obiect suportă capacitatea obiectelor de a se 
referi direct unele la altele cât si facilitatea de calcul a limbajelor orientate obiect 
de a procesa obiecte. 


Totodată, un model de întreprindere ar trebui să fie un model ce descrie tipuri de 
obiecte, de afaceri, subtipuri, comportarea lor, relaţiile dintre obiecte, stările 
KK RUMOR bini (e NM Toal de ii ee 

Modelul întreprinderii trebuie translatat direct in software care face ca 
întreprinderea să funcţioneze. O astfel de situație necesită baze de date care 
stochează obiecte şi fac metodeie asociate să fie operative. 


BDOO permit obiectelor să se refere direct unele la altele pe bază de pointeri. O 
astfel de adresare (referire) face BDOO mai rapide în a ajunge de la obiectul X la 
Y decât bazele de date relaţionale, care trebuie să folosească un operator de JOIN 
pentru a realiza acest lucru. Chiar un JOIN optimizat e tipic mai încet decât o 
referire directă la obiect pe bază de pointeri. 


BDOO oferă performante sporite referitoare la clasterarea (cluster) fizică a 
datelor. Majoritatea sistemelor de baze de date permit proiectantului să plaseze 
structurile legate aproape una de alta pe suportul de memorie externă. Prin 
clasterare se urmăreşte sporirea vitezei de răspuns la cererile utilizatorilor ce 
implică operaţia de joncțiune a unor structuri de date. Se reduce astfel în mod 
timpul de regăsire pentru datele solicitate, prin reducerea numărului 
de accese pentru citirea datelor de pe hard disc. Exemplu, pentru a da răspuns 
facil la o cerere de aplicaţie de forma: care sunt subpárjile componente ale unui 
produs oarecare sau se cere să se listeze informaţiile despre salariaţii şi 
departamentele unei societăţi comerciale în care lucrează aceștia. 
În astfel de situaţii proiectanfii recurg la definirea de clastere (Clusters). În 
condiţiile BDOO clasterarea fizică se realizează la un singur nivel, de unde 
rezultă şi performanțele sporite sub aspectul timpului de regăsire. Logica de 
clasterare se bazează pe clase şi ierarhii de agregare. Obiectele care formează 
grupe sunt stocate laolaltă cu obiectele ite şi într-un sistem bine proiectat, 
structurile de clasificare sunt folosite ca bază naturală de clasterizare, pe când, în 
condiţiile BDR se impune un al doilea nivel de claster. Un prim nivel pentru 2 
grupa tuplurile reprezentând obiectele individuale şi un al doilea pentru grupurile 
de tupluri reprezentând obiectele referite. 


BDOO sporesc extinderea domeniilor de aplicabilitate prin posibilitatea folosirii 
diverselor structuri de stocare si prelucrare a datelor. Într-o bază de date 
relationalá, datele care nu pot fi exprimate în formă tabelară sunt difici! de stocat 
şi accesat eficient. Ori, există o multitudine de aplicaţii care implică date 
complexe, sunet, imagini, text neformatat ete. Modul de stocare pentru BDOO 
este nelimitat, din moment ce sistemul este extensibil prin natura sa. BDOO pot 
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Lipsa unor standarde ale arhitecturii de SGBDOO, de modelare a datelor sau de 


limbaje de integrare standard orientate obiect. Există totuşi preocupări şi chiar 
anumite realizări de standardizare pe domeniile amintite, în mare parte aparținând 
grupului de administrare a bazelor de date orientate obiect (ODMG). 
SGBDOO nu oferă o gamă largă de instrumente (TOOLS) utilizatorilor firmei 
sau proiectanfilor de dezvoltări şi întreţineri de aplicații, comparativ cu SGBDR. 
SGBDOO nu oferă suficientă siguranță in ceca ce priveşte rezolvarea 
problemelor de acces concurent în condiţiile lucrului cu volume mari de date. 
Nu sunt rezolvate in suficientă măsură problemele referitoare la asigurarea 
integrităţii bazei de date sub aspectul refacerii acesteia în caz de incident, 

poate genera dificultăţi sub aspectul optimizării integrării bazei de 
date. Felul in care sunt definite şi stocate datele și metodele precum si limitele 
Limbajelor de interogare orientate obiect pot influența în sens negativ 
performanţele de ordin fizic ale bazei de date. Acelaşi lucru poate să apară şi în 
situaţia în care avem de a face cu anumite cerințe informaţionale care nu au fost 
prestabilite. Cu alte cuvinte, apare întrebarea: Cum pot fi căutate şi regăsite 
anumite obiecte a căror structură este incapsulatá (ascunsă), dacă o astfel de 
cerinţă nu a fost prevăzută încă din faza de proiectare. Remarcăm faptul că unele 
SGBDOO de dată mai recentă acceptă interogările de tip AD-HOC însă, acest 
lucru îl realizează prin distrugerea încapsulării sau prin impunerea unor limite 
privind interogările posibile. 
Lipsa de experienţă în domeniu, comparativ cu experiență dobândită în sistemele 
tradiţionale. Această lipsă de experienţă poate fi datorată cel puțin de următorii 
factori: 

e este un domeniu mai nou de preocupare; 

* SGBDOO prin componentelor lor sunt mai mult orientate spre 
programatori decât spre utilizatorii finali neinformaticieni; 

* se simte o trecere abruptă de la sistemele tradiţionale la cele orientate 
obiect, iar, înțelegerea şi însuşirea noului mod de abordare impune 
eforturi sporite din partea proiectanfilor şi utilizatorilor. Acest aspect 
generează o oarecare rezistenţă în acceptarea tehnologiei orientate obiect. 
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7.4. Comparatii între abordarea obiectuală și cea 
relationalá privind modelarea datelor 


Prezentarea. asemănărilor și deosebirilor dintre modelarea relafionalá şi modelarea 3 
orientată obiect a datelor este semnificativă şi de mare importanţă atât pentru proiectanfii d 
baze de date cât si pentru utilizatori. i 

Proiectanii, cunoscând foarte bine modelul relational şi apoi sesizând asemănările si | 
deosebirile dintre cele două moduri de abordare a modelării datelor, vor putea valorifica şi 
folosi experienţa dobândită anterior ca bază substanțială pentru înjelegerea şi însușirea . 
metodologiei de proiectare a bazelor de date orientate obiect. Totodată, prin cunoașterea | 
asemănărilor şi deosebirilor dintre cele două moduri de abordare apare posibilitatea 
conversiei unui model relaţional in obiectual si invers. De altfel, o astfel de practică o 
regăsim în mod frecvent. 

În cele ce urmează vom recurge la o prezentare comparativă a modelării datelor, - 
luând in considerare conceptele folosite precum si obiectivele urmărite. $ 

În tabelul 7.1 se prezintă o comparație între principalele concepte utilizate în. 
modelarea obiectuală si relajionalá a datelor. 


Tabelul 7.1. Compararea BDOO şi BDR sub aspectul conceptelor folosite 


Modelul orientat pe | Modelul - 
obiecte elațional Diferenie : 
[Obiect Entitate 


Clasa de obiecte Tipuri de entități | Clasa de obiecte include şi comportamentul 
comun obiectelor din clasa respectivă 

Schema bazei de | Ierarhia de clase implică moştenirea iar schema 
date implică chei exteme 

Instanță de clasă | Entitate, tuplu sau | Instanţa poate avea un caracter mai restrictiv 


Ierarhia de clase 


| înregistrare 

Atribut | Atribut Fără diferenţe 

Relaţii Relaţii Fàrà diferenţe 
Au semnificaţia de descrieri, însă în BDOO 
moştenirea include atât starea cât şi 

Mesaje 7 interfață — | Nu există 

Incapsulare Nu există 
Identificatorul de Cheie primară modelul relafional dacă nu se defineşte cheia 
obiect (OID) primară sistemul generează în mod automat un 


Deosebirile dintre modelul BDOO şi modelul BDR pot fi evidenţiate şi sub m, 
obiectivelor urmărite sau prin alte caracteristici, aşa cum se poate observa din tabelul 7.2. 


Baze de date orientate obiect 
Tabelul 7.2. Compararea p BDOO şi BDR sub obiectivelor urmărite 
BDR 

Obiective us Eden Fi Obiectiv principal: asigurarea independenţei 
independenţa datelor. datelor faţă de programele de aplicaţii. 
independența claselor: pot fi reorganizate fără | Independenţa datelor: datele pot fi 
a afecta modul de folosire a lor. reorganizate si modificate fizic fără a afecta 

modul de folosire. 
BDOO stochează date şi metode. BDR stochează numai date. 
Încapsularea: datele pot fi folosite numai prin | Partiţionarea datelor: datele pot fi 
metodele claselor. pertiţionate in funcție de cerințele si 

specificul aplicaţiilor utilizatorilor. 
Obiecte active: obiectele sunt active. Date pasive: datele sunt pasive. 
Cerinţele cauzează obiectelor executarea operaţii limitate pot fi în mod automat 
metodelor acestora. | antrenate când datele sunt folosite. 


Complexitate: structura datelor poate fi 
complexă, implicând multiple tipuri de date. 


Simplitate: utilizatorii percep datele sub 
formă de coloane, rânduri / tupluri si tabele. 


Date inlánjuite. Datele por fi înlănțuite aşa 
încât metodele claselor oferă performanţe 


Tabele separate: fiecare relaţie / tabelă este 
separată. Operatorul de JOIN referă date din 


sporite. Datele structurate precum si BLOB 
(binary large objects) sunt folosite pentru 
sunet, imagine, video etc. 


tabele separate. 


Neredundanţa metodelor: neredundanga 
datelor şi metodelor sunt realizate prin 
incapsulare şi moştenire. Moştenirea ajută la 
reducerea redundantei metodelor. 


Neredundanja datelor: Normalizarea datelor 
are ca scop de a elimina sau reduce 
redundanfa datelor. Ea este folosită în faza 
de proiectare a bazei de date şi nu în fază de 
dezvoltare a aplicaţiilor. 


| Optimizarea datelor: datele pentru un obiect 


| mecanismul de acces. 


Performanța BDR este legată de nivelul de 
pot fi interlegate şi stocate împreună, astfel complexitate a structurii datelor. 


încât ele pot fi accesate împreună de 


| Model conceptual consistent: modelele 


Model conceptul diferit: modelul structurii 
datelor şi acces reprezentat prin tabele şi 
JOIN-uri este diferit de cel în analiză, 
proiectare şi programare. Proiectul trebuie 
să fie convertit în tabele relationale și acces 
conform SQL. 


folosite pentru analiză, proiectare, 
programare şi accesul bazei de date sunt 

| similare. Conceptele aplicațiilor sunt in mod 
| direct reprezentate prin clasele de obiecte. 


Analizând cele două tipuri de baze de date, obiectuale şi relafionale, por fi desprinse 
o serie de concluzii, dintre care amintim [21,51,73]: 

- O bază de date relațională este formată din relaţii, care sunt seturi de tupluri, în 
timp ce o bază de date orientata pe obiecte este formată din clase, care sunt seturi 
de obiecte; 

- Într-o bază de date relaţională, componentele unui tuplu trebuie să fie tipuri 
primitive (real, integer, strings etc.), în timp ce într-o bază de date orientată pe 
obiecte, componentele unui obiect pot fi atât tipuri primitive cât şi tipuri 
complexe (seturi, tupluri, liste, BLOB-uri etc.); 

- Bazele de date orientate pe obiecte au anumite proprietăți pentru care nu găsim 
analogie în bazele de date relajionale, cum ar fi proprietatea de moştenire şi 
metodele aparținând obiectelor; 


tabelele relafionale legându-le de Obiectele mari lineare (BLOB — Binary Large 
Object). 

- Regándirea în totalitate a arhitecturii sistemelor de gestiune a bazelor de date si 
producerea unei noi arhitecturi care să facă faţă noilor tehnologii orientate obiect. 
Conform acestei variante se are în atenţie sporirea substanțială a performanţelor 
de ordin fizic a bazelor de date comparativ cu modelul relational în ceea ce 
priveşte stocarea informaţiilor complexe. 


7. În anumite sisteme de baze de date orientate pe obiecte, limbaj manipulare 
12 p de 
datelor şi limbajul gazdă sunt aceleaşi; ie le 1 
~ + Bazele de date relationale au ca obiectiv principal asigurarea independen yei 
datelor. Datele normalizate sunt separate de prelucrări iar, prelucrările 


7 Bazele de date orientate obiect au ca obiectiv principal încapsularea, fiind stocate 


- Nevoia unui SGBDOO şi nu unul relați i icații 
P e psa ia en apare atunci când în aplicațiile de 
- Limbajele de programare necesită o nouă sintaxă; mixarca, reproducerea şi noile 
metode de acces necesită de asemenea continuarea cercetărilor; trebuie realizate 
aerian mai ape ale limbajelor de interogare; se simte nevoia continuării 
pu X : uisa : 
Dep ui concurenţei, semantica mărcilor de timp şi concurenței 
~ Limbajul C++ nu este un limbaj prea adecvat pentru implementarea bazelor de 


716. Modelul conceptual al datelor obiect (CODM*) 


Modelarea reprezintă un proces de abstractizare a mediului înconjurător în scopul 
„ simplificării înţelegerii şi redării mai facile a acestuia. 
- Abstractizarea presupune ignorarea anumitor aspecte considerate nesemnificative în 
favoarea reţinerii a celor mai interesante şi reprezentative, 
Mediul înconjurător poate fi considerat ca un sistem, subsistem sau parte a acestuia. 
Pentru modelarea unor realităţi, activităţi, procese sau fenomene economice din 
domeniul de interes se recurge la utilizarea a diferite metode, tehnici sau instrumente, cum ar 
fi: 
utilizarea anumitor tipuri de diagrame sau grafice ; 
prezentarea textuală a problematicii de referință; 
redarea fenomenelor şi proceselor economice în limbaje formale; 
sintetizarea şi redarea aspectelor de interes sub formă de scheme logice etc. 


sistemelor de gestiune, cum ar fi: înregistrarea în jurnal a tranzacţiilor 
refacerea prin derulare înainte; un monitor multifir ü tranzacţiilor, in limbaj de 
interogare si un procesor de interogări ; . 

- Piaţa bazelor de date orientate obiect va continua să crească, dar va rămâne încă 
doar o fracțiune din piața tradițională a bazelor de date ; 

~ Se apreciază că SGBDR deţin ponderea cea mai mare pe piaţa bazelor de date, 
însă ca perspectivă ele vor coexista încă mult timp împreună cu SGBDOO. 


În contextul sistemelor informatice în general, si în special al bazelor de date, se 
poate recurge la modelarea și implicit elaborarea a o serie de modele, cum ar fi: = 
Modelarea domeniului (The Domain Model), s 
Modelarea proceselor de afaceri (The Business Process Model), 

Modelarea structurii statice a sistemului (The Static Model), 
Modelarea dinamicii sistemului (The Dynamic Model), 
Modelarea datelor (The Date Model). 

Remarcăm faptul că modelarea tuturor aspectelor amintite anterior se referă la acelaşi 
sistem, însă prin fiecare tip de model se urmăreşte satisfacerea cerințelor informaționale de 
interes a unei anumite categorii de utilizatori. Pentru a modela astfel de procese sau 
activităţi, în cele ce urmează vom evidenția şi defini conceptele cu care se va opera în 
contextul UML (Unified Modeling Language). 


7.5. Moduri de abordare ale dezvoltării sistemelor 
de BDOO 


Ținând seama de multitudinea avantajelor oferite de modelul BDOO, se pune 


- roi unui sistem de gestiune de bază de date convențional existent și 
lugarea unui strat po pentru procesarea cerințelor orientate obiect si 


metodelor de stocare. Într-o astfel de abordare sistemul de gestiune a buzei de 7.6.1. Conceptul de obiect 


Un obiect este o entitate cu un rol bine definit în sistem, caracterizat de proprietăți, 


implementa o bază de date orientată obiect mult mai repede decât dacă s-ar pori stare, comportament şi identitate. La modul general, prin obiect vom înțelege ceva asupra 

de la conceperea şi dezvoltarea tuturor componentelor sistemului de gestiune a căruia se poate întreprinde o acțiune, sau care poate declanșa / efectua o acţiune. 

bazei de date. Exemplu: persoană, maşină, factură, contract, salariat, chitanjà casă etc. Obiectul 
~ Adăugarea de funcționalități orientate obiect unui sistem de gestiune a bazei de Poate fi concret (o entitate tangibilă şi vizibilă, de exemplu o persoană, o masă, o floare etc.), 


date relajional. Într-o astfel de situaţie se contează pe i icile şi 

re k pe instrumentele, tehnicile şi 
experiența vastă a tehnologiei relaionale care pot fi folosite pentru a reconstrui 
un nou sistem de gestiune a bazelor de date. Pot fi adăugaţi pointári (pointers) la — 'CODM- The Conceptual Object Data Model 
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Baze de date orientate obiect 


o entitate abstractă (un concept, un eveniment, idee, un departament etc.) sau un artifact 
procesului de proiectare (de exemplu, interfață cu utilizatorul, control, planificare). 

Proprietăţile unui obiect sunt date de atributele prin care se descriu caracteristicile. 
obiectului respectiv. Starea unui obiect este dată de valorile pe care le iau proprietăţile sale 
la un moment dat. 

Comportamentul arată modul în care un obiect acţionează sau reacționează la 
evenimente. O operaţie este o simplă acţiune pe care o execută un obiect asupra altui obiect 
pentru a primi un răspuns. 

Multitudinea operaţiilor pe care le poate efectua un obiect sau se efectuează asupra asupra | 
acelui obiect implementate într-un limbaj de programare poartă denumirea de metode, iar 
multitudinea metodelor se spune că definesc comportamentul obiectului de referință. Un 
obiect îşi expune comportamentul prin intermediul operaţiilor care îi pot afecta starea. 

Să considerăm cazul unui student ION, reprezentat ca obiect. Obiectul student are 
următoarele atribute: nume, data-nașterii, adresa şi telefonul. Starea obiectului este dată de 
valorile asociate acestor atribute: „ION”, „23-03-85”, „Mihai Bravu nr.6”, „4438601”, 
Comportamentul studentului este dat de operații cum ar fi: schimbare-domicilu, schimbare | 
telefon, trecerea într-un nou an de studii ete. 

“Toate obiectele au o identitate, astfel că nu există două obiecte identice. Dacă exist i 
două obiecte (instanțe) de tip student cu aceleași valori asociate atributelor (aceleaşi nume, 3 
aceeaşi adresă, același telefon si aceiaşi dată de naştere) este vorba, totuși, de două obiecte | 
diferite, Chiar dacă obiectele au valori identice ale atributelor, ele au identități diferite. Un. 
obiect îşi păstrează identitatea de-a lungul existenţei sale. Exemplu, dacă studentul ION se 
căsătoreşte sau își schimbă domiciliul, el va fi reprezentat de același obiect. 

În mod formal un obiect reprezintă o pereche de forma «id, Val», ce 
identificatorul obiectului, iar «val» este o valoare aparţinând obiectului. Valoarea <Vab 2 
PARIA tun cd Cre INTARI EE 

Valoare primitivă. Un membru de tip de dată Integer, String, Float sau Boolean; < L 
exemplu: „B 54 PDD”; 

- Valoare referință. Un OID a unui obiect, exemplu: # 123; 

- Valoare tuplu de forma [A, :v,,...., A, :v, ], unde 4,....,4, sont nume de atribute $ 

distincte şi v,,..., v, sunt valori asociate atributelor; 

= Set de valori, de forma (v,,...,v,) unde v,,...,v, sunt valori. Exemplu , numere 

de telefoane ale unei persoane: "021-3348601", "021-1234567". 


— 


Exemplu: presupunem un obiect, din cadrul sistemului bancar românesc, BCR, cu — 
următoarea descriere: 
(#11, [cod — fiscal: 123456, 
Denumirea: BCR, 
Preşedinte: Rădulescu, 
Nr. telefon: ("021-1234567", "021-7654321"), 
Sucursale: (8 333, & 444, 4 555, # 666), 
Localitate: Bucuregti]) 


- simbolul # 11 reprezintă OID-ul obiectului cu denumirea BCR; 
între 


din mra 


- între parantezele acolade { ), se specifică seturi de valori cum sunt numerele de 
telefoane si OID-urile sucursalelor băncii; 
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- referinjele către sucursalele ce aparțin băncii "mamă”-BCR, sunt precizate prin 
OID-urile acestora (4 333, 444,4 555, # 666). 


Obiectele pot fi simple sau complexe. Un obiect simplu apare ca un articol sau 
entitate din mediul înconjurător ce nu poate fi descompus sau nu se justifică descompunerea 
acestuia; el este tratat ca un Întreg. 

Exemplu: persoana, porumbel, medicament etc. Un articol complex apare ca o 
entitate sau articol din mediul înconjurător care este privit ca un singur obiect însă acesta se 

combina cu alte obiecte printr-un set de relații, cum ar fi: "B este parte a lui A" sau "A 
este format din B, C, D ... . Obiectele B, C, D, ... conținute de A, la rândul lor pot fi 
complexe, ceea ce în final face să asistăm la o ierarhie de obiecte. Exemplu, un obiect 
complex, "Automobil" poate fi privit ca un obiect format dintr-o serie de componente care la 
rândul lor sunt privite ca obiecte, de forma (figura 7.1). 

aci carae cute: dont ogor prăzii iaiia cet aur 
manipulării obiectului conținut. Un obiect conținut poate fi în două moduri, Într- 

un prim mod, obiectul conţinut poate fi încapsulat în obiectul complex si astfel formează o 
parie a acestuia. to astfel de situație, structura obiectului conţinut reprezintă o parte a 
structurii obiectului complex, iar obiectul conţinut poate fi accesat numai cu metodele 
obiectului complex. În al doilea mod, un obiect conţinut poate fi considerat ca având o 

existenţă independentă de cea a obiectului complex. În acest caz, în obiectul părinte nu este 
stocat pue obiectul membru, ci doar identificatorul său OID. Obiectul conţinut are structura 
si metodele lui proprii şi poate fi deţinut de diverse obiecte părinte. 


AUTOMOBIL 


Fig. 7.1. Obiect complex 


7.62. Identificatorii obiectelor 


Aşa după cum s-a mai precizat, fiecare obiect are o identitate unică şi stabilă, numit 
COGI obiecti OD (Ohjeet isa cuc tatea a coana tuni 


MO u e Par ais Baer A os or icd 
Creării/incărcării bazei de date. El este invizibil pentru utilizatori, independenţi de valorile 
atributelor sale şi stabil pe toată durata de existenţă a obiectului si chiar mai mult decât atât, 
dacă obiectul respectiv este şters din baza de date OID-ul acelui obiect nu se atribuie ulterior 
nui alt obiect. 


=- pa M — 


-— —S 9 3) 


Observăm asemănarea şi deosebirea dintre OID şi cheia primară a unei lii. Ca şi 
OID-ul cheia primară oferă posibilitatea identificării unice a oricărui tuplu/obiect, însă 
valoarea cheii primare este unică doar la nivelul unei tabele si nu la nivelul întregului sistem 
ca şi OID-ul, iar pe de altă parte, valoarea cheii primare poate fi schimbată în timp. 

lu, presupunem un obiect „automobil” având cheia primară „numărul de 
înmatriculare în circulație”. Totodată presupunem faptul că proprietarul vinde „automobilul” 
unei alte persoane. Cu această ocazie poate fi schimbat „numărul de înmatriculare”, deci 
implicit valoarea cheii primare, desi „automobilul” rămâne fizic acelaşi şi chiar în aceiași 
bază de date la poliţie. În contextul bazelor de date orientate obiect OID-ul automobilului 
rămâne acelaşi doar că se schimbă proprietarul. 

Faptul că OID-ul este unic la nivelul întregului sistem şi invariabil în timp prezintă o 
importanță deosebită sub aspectul asigurării mai facile a integrităţii entităţilor si a celor 
referenjiale. 

Dacă în urma ştergerii unui obiect din baza de date OID-ul acelui obiect ar fi atribuit 
unui alt obiect, o referinţă anterioară la OID-ul obiectului şters s-ar putea menţine, însă de 
această dată OID-ul referit ar aparţine unui alt obiect. Deci în realitate nu ar fi respectată și 
menţinută integritatea referenfialá. Exemplu: presupune o relație referențială între obiectul 
»Pürinte" şi „Copil”. Dacă Părintele unui copil ar fi şters din baza de date si OID-ul acestuia 
ulterior ar fi atribuit altui Părinte, în contextul posibil de a se menţine relaţia referentialà s-ar 
ajunge la situația în care un copil ar aparține unui alt părinte decât cel inițial declarat. 

O altă problemă ce merită a fi prezentată, izvorăşte din faptul că identificatorii OID 
ca mecanism pentru identitatea obiectelor sunt independente de conţinut, în sensul că 
identificatorii OID nu depind în nici un fel de datele conţinute în obiect. Într-o astfel de 
situaţie, două obiecte pot părea utilizatorului aceleaşi (ele având toate valorile atributelor 
aceleaşi) şi totuşi au identificatori OID diferiţi, fiind astfel obiecte diferite. Ținând seama de 
faptul că identificatorii OID sunt invizibili pentru utilizatori, atunci ne întrebăm cum poate 
distinge utilizatorul aceste două obiecte? Dintr-o astfel de stare putem desprinde concluzia că 
sunt încă necesare cheile primare, pentru a permite utilizatorului să distingă obiectele. 

În încheierea acestui paragraf, facem precizarea că există o serie de mecanisme, 
tehnici şi algoritmi pentru identitatea obiectelor, cum ar fi: identitatea obiectelor bazate pe 
valoare, identitatea folosind numele variabilelor şi pointerii sau adresele de memorie 
virtuală, identificatori OID logici si fizici, tehnici de mixare a pointerilor ete. Despre astfel 
de probleme, si chiar mai multe, cei interesaţi pot consulta o serie de alte materiale [81,12]. 


7.6.3. Atribute — proprietăţi ale obiectelor 


Fiecare obiect din mediul înconjurător comportă o anumită descriere ce se realizează 
cu ajutorul atributelor. Multitudinea atributelor prin care se descrie un obiect definesc 
proprietăţile acelui obiect. 

Atributele pot fi simple sau complexe, care la rândul lor pot fi referenfiale, de 
colecţii şi derivate. 

Pentru exemplificarea ne vom referi la descrierea a două entităţi, astfel (figura 7.2.): 


are l* 
DEWEESMENT p 13 ———— 


aparține de 


SALARIAT 


DEPARTAMENT: { 
Denumire: STRING; 
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Cod - dep: INTEGER; 
Şef - dep: SALARIAT: 
Nr. — telefoane: SET [STRING]; 


Profesia: STRING; 
Data-naşterii: DATE; 

Funcţia: STRING; 

Loc-muncă: DEPARTAMENT ) 


Fig. 72. Exemple de atribute 


unde: 

Atributele simple pot fi un tip de date atomic, care include tipurile de date clasice 
prezente în limbaje de programare, cum ar fi: întreg, real, boolean şi şiruri de caractere. În 
exemplul din figura 7.2, denumire, cod-dep, marca, funcția pot fi considerate ca atrib:te 
simple. 

Atributele referențiale sau de asociere, sunt folosite pentru a defini relaţii referez;: 
între obiecte. Ele sunt echivalente pointerilor din limbajele de programare sau che: 
externe în cazul sistemelor relationale, însă prezintă si diferenţe importante, astfel: 

- Contrar pointerilor, atributele referenfiale sunt incoruptibile sau nealterabii 
sensul că dacă obiectul referit a fost şters din baza de date atunci atribu 
referenţial în mod automat va fi invalidat; 

- Contrar cheilor externe, atributele referenjiale nu sunt asocieri de valori vi 
utilizatorilor. În exemplul nostru din figura 72. atributele "Sef-. 
SALARIAT” si "Loc-muncá: DEPARTAMENT” sunt atribute referenfiale. 

Atributele colecţii făcând parte din categoria atributelor complexe pot fi la rândui tor 
grupate in seturi, liste si tablouri de valori. 

Atributele colecţii vor conjine fie valori ale atributelor simple fie referinţe. 

În exemplul din figura 7.2. "Nr.-telefoane" este un atribut de tip SET şi va conține 
multitudinea numerelor de telefon pe care le are un Departament, iar "Angajaji" este tn 
atribut de tip LIST şi va conține ca valori multitudinea identificatorilor OID ale Salariașilor 
ce lucrează într-un anumit Departament. 

Atributele derivate le mai regăsim şi cu denumirea de atribute de proceduri. Uneori, 
în practică, in loc de a stoca în mod explicit valoarea unui atribut, este de preferat de 2- 
determina sau calcula printr-o procedură oarecare şi apoi a-l da disponibil și a-l face 
cunoscut celor interesaţi. Pe considerentul că valoarea unui atribut derivat se deter: 
Printr-o metodă de tip procedură sau "funcjie", atributul respectiv mai poartă denumirea de 
atribu procedură. În exemplul nostru de referință nu apare un atribut derivat, însă ar putes fi 
definit unul cu denumirea sugestivă " Vársta" salariatului. Într-o astfel de situație Vârsta” ar 
putea fi determinată cunoscând Data-nasterii şi apoi preluând data curentă de sistem. Prin 
diferență se obține vârsta. 
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7.6.4. Tipuri şi clase de obiecte 


7.6.4.1. Tipuri de obiecte 


„_În literatura de specialitate nu există o unanimitate de păreri cu privire Ja definirea şi 
conceptelor de tipuri şi clase de obiecte. Astfel, întâlnim situaţii in care unii | 
erei iapa cd alți de clasă iar o altă categorie folosesc atit. 
conceptul de clasă cât și conceptul de tipuri, aga după cum se va putea vedea în cele ce | 
urmează, 

R.G.G. Cattell [10] foloseşte doar conceptul de tip deşi recunoaşte şi conceptul de 
clasă, însă pentru a înlătura anumite ambiguităţi, în lucrare renunţă la folosire termenului de 
clasă, acesta având cel puţin următoarele semnificaţii: 

- O clasă defineşte un tip care este o intensie, adică structura şi comportamentul ` 
obiectelor de un tip particular. Conceptul de tip este folosit pentru a proiecta o 
intensie. Intensia va regrupa structura (atributele şi relaţiile obiectului) precum şi - 
comportamentul (metodele asociate tipului); 1 

* O clasă defineşte o extensie, adică un ansamblu de obiecte de un tip particular; 3 

- O clasă la rândul ei poate fi considerată ca fiind tot un obiect sau meta-obiect | 
dispunând de atribute, relaţii şi metode proprii. Aceste proprietăţi, relații şi - 
metode au semnificație doar la nivelul întregii clase $i nu la nivelul obiectelor ce ^ 
fac parte din clasă. Exemplu, un atribut având semnificația de SUMA valorilor 
tuturor factorilor din clasa FACTURI, are semnificaţie doar la nivelul întregii ^ 
clase de obiecte şi nu la nivelul fiecărui obiect. d 

R.G.G. Cattell pentru a defini conceptul de tip recurge la o analogie cu modelul - 
relational, considerând că tabelele din modelul relational sunt definiri de tipuri iar tuplurile — 
(liniile) unei tabele sunt instanțe de tupluri. | 

Thomas Connolly [81 precizează cà, adesea, în literatura de specialitate, termenii de 
"tip" şi "clasă” sunt sinonimi, cu toate că anumiţi autori fac o distincţie între ei, aga cum se 
va preciza in continuare. Un tip corespunde noţiunii de tip de date abstract. Pe de altă parte, ` 
o clasă defineşte modul de creare a obiectelor şi formează metode care pot fi aplicate 
fete e tu Rete e sie ai poe ast pa eer 

proprietăţilor si comportamentului obiectelor. Într-un astfel de context, pe parcurs au fost — 
create două modele de sisteme de gestiune a bazelor de date orientate obiect, astfel: 

- unele care folosesc ca termen de bază clasa, dintre care amintim Smalltalk, Orion, 
ITASCA, Object Store, Vision etc.; 


aS; PE 


O astfel de situaţie o întâlnim si la nivelul limbajelor de programare. De exemplu, 
limbajul C+ foloseşte conceptul de clasă, pe când SQL3 recurge la utilizarea i de 
"ip". În acest fel definirea tipului în SQL3 este similară cu definirea simplificată a clasei în 
CH. 


consideră că tipurile si clasele de obiecte sunt înrudite (legate) 
această categorie amintim câțiva : Michael Kifer, Paolo Alzeni [40,51,65]. 
Într-o bază de date orientată obiect tipurile permit definirea proprietăţilor obiectelor, 
atât cele statice (descrierea structurii obiectelor) cât şi dinamice (descrierea 
comportamentului obiectelor ca metode aplicabile obiectelor). Referitor la partea statică a 
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Baze de date orientate obiect 


————— 


tipurilor, aceasta este construită utilizând constructorii de tip si un set larg de tipuri de dare 

atomice, care includ tipurile de date clasice prezente în limbajele de programare, cum ar fi: 

intreg, real, boolean si şiruri. Tipurile de date atomice includ şi identificatorii de obiecte 

(01D). 

S. dania tipuri permit definirea tipurilor numiți tipuri de date complexe, care 

dictează structura instanțelor (numite obiecte complexe) a unei baze de date obiect. 

Reprezentarea unui tip se face conform unei expresii de forma: 

[CNP: integer, Nume: String, Nr. telefon: (string), copii: (PERSOANA]] 

Această definire de tip precizează faptul că atributele: CNP acceptă valori de tip 
"integer", Nume acceptă valori din domeniul primitiv "string" (şir de caractere), Nr. telefon 
trebuie să ia valori ce sunt "set de şiruri” de caractere, iar valorile atributului "copii" sunt 
seturi de obiecte ce aparţin clasei PERSOANA. Totodată, se poate observa că expresia 
anterioară descrie un tip (model) în care structuri complexe pot fi incluse în interiorul altor 
structuri. De exemplu, valorile pentru "Nr. telefon” sunt seturi de valori primitive, în timp ce 
valorile pentru "copii" sunt seturi de obiecte provenite din clasa PERSOANA. 

În mod intuitiv se poate deduce faptul că, tipul unui obiect este tocmai colecția 
tipurilor componentelor acestuia. Constructorii tip permit definirea de tipuri numite tipuri de 
date complexe, care dictează structura instanțelor numite obiecte complexe a unei baze de 
date obiect. Mai precis, o definire recursivă a tipurilor de date complexe corespunzătoare 
— obiectelor complexe, bazată pe constructori de tip, apare astfel: 

tipuri de bază (valori primitive): întreg, şir, real şi boolean; exemplu: "BIOXYZ" 
ar putea fi valoarea asociată atributului numărului de înmatriculare în circulaţie a 
autovehiculului deseris astfel — Nr. MAŞINA: STRING; 

- tipuri referință: Numele claselor definite de utilizator, cum ar fi SALARIAŢI si 
ECONIMISTI, unde ECONOMISTIT referă SALARIATII, sau un alt exemplu ar 
putea fi de forma unui OID al unui obiect. 

- tipuri set şi liste: Constructorii de tip SET şi LISTE permit definirea de tipuri ale 
căror instanje sunt colecții de valori (posibil complexe) de același tip. Seturile 
sunt colecții neordonate ce nu acceptă duplicări, iar listele sunt colecţii ordonate 
cu posibile duplic&ri. Valorile din cadrul setului pot fi de orice tip. În exemplul 
anterior au fost întâlnite următoarele seturi: 

* Nr. telefon: (string), reprezintă un set de şiruri de caractere cu 
semnificaţia că stochează multitudinea numerelor de telefoane pe care le 
are o persoană, de forma: ("040-021-334861", ..., "040-021-3359211"]; 

e Copii: (PERSOANA"), reprezintă un set de obiecte aparținând clasei 
PERSOANA. 

- tipuri înregistrare / tuplu: un constructor înregistrare permite definirea de tipuri a 
căror instanțe sunt tupluri de valori de diferite tipuri posibile. Constatăm faptul că 
şi în această privinţă unii autori folosesc doar conceptul de constructor tuplu nu şi 
înregistrare [40], însă sub aspectul formalizării matematice lucrurile sunt foarte 


apropiate. Dacă Ti, ..., Ta, sunt denumiri de tipuri şi A, ..., As sunt denumiri de 
atribute distincte, atunci: 
T = înregistrare de [Ay'Ty, ..., An:TaJ este un tip înregistrare. 


Deosebirea dintre cele două alternative se observă doar la nivelul limbajelor de 
definire fenis, în funcţie de specificul acestora. 


[CNP: Mns Nume: string, An-studii: integer, Adresa: 
[Localitate: string, Strada: string, Numár: integer]] 


ME M p p 1 E 


Această definire reprezintă un tip înregistrare (RECORD) în care primele ei 


componente (atribute) au tipuri de date de bază, iar al patrulea (Adresa) este de tip tuplu. 
Deci, se poate constata faptul că avem de a face cu un tip înregistrare în cadrul căruia apare 
un subtip tuplu "Adresa", În mod intuitiv se poate desprinde concluzia că puteam avea de a 
face cu subtipuri şi supertipuri de date complexe, corespunzătoare obiectelor complexe. 
Totodată precizăm faptul ca în mod obişnuit în cele mai multe sisteme orientate obiect o 
definire de tip de dată are constructorul înregistrare (RECORD) la nivelul cel mai înalt. 


Din punctul de vedere al bazelor de date orientate obiect, o clasă poate fi considerată 


ca un tip înregistrare constând din metadata care asigură întreaga informaţie necesară pentru 
a construi și a folosi un anume obiect. Totodată e posibil de a considera instanțele unei clase 
ca fiind înregistrări stocate într-un fişier. Noile înregistrări având diferite valori pot fi 
adăugate în fişier. Un dicţionar de date pentru SGDB poate confine descrieri a mai multor 
tipuri diferite de înregistrări, fiecare cu un set diferit de atribute, aşa după cum se va putea 
constata şi în exemplul ce urmează. 


Pentru exemplificare vom considera un obiect complex referitor la structura unei 


Universităţi, unde: 


O universitate poate avea cel puţin două facultăți regăsite în aceeaşi localitate cu 
sediul Universităţii sau în localităţi diferite; 

-  O facultate poate avea sau nu specializări pe secţii; 

- În cadrul unei Universităţi pot exista unul sau mai multe laboratoare pe care le 
pot folosi oricare dintre facultăţi, dacă prezintă interes şi există un acord în acest 
sens; 

- La nivelul unei Universităţi pot exista una sau mai multe biblioteci, amplasate 
într-un singur corp sau în mai multe corpuri de clădiri; 

-  Catedrele ca departamente, din punct de vedere administrativ şi al coordonării 
acestora sunt arondate facultăţilor, 

- O Universitate dispune de un corp didactic. propriu, organizat pe Catedre de 
specialitate; 

- Un profesor poate preda una sau mai multe discipline la o facultate sau la mai 
multe facultăţi. 


În situaţia în care la nivelul Ministerului Învăţământului şi Cercetării ar prezenta interes 
proiectarea unei baze de date care să permită evidenţierea multitudinii unităţilor de 
învăţământ superior din România, precum şi a altor aspecte, necesare elaborării unor 
studii de analiză, prognoze, evaluări comparative etc., diagrama tipurilor de obiecte at 
putea fi redată astfel (figura 7.3.). 
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solicită carte 


foloseşte 


frecventat de 
Fig. 7.3. Diagrama tipurilor de obiecte 
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Baze de date orientate obiect 
Pe baza diagramei tipurilor de obiecte, sc poate trece la definirea structurii bazei de, p . 
date orientate obiect, însă ne vom limita doar la o parte a acesteia, astfel (figura? 4.).. Facultăţi: record - of (Denumire: string, 
Universitate: record of ( Nume-decan: string, 
Denumire: 


Nume-rector: — si 
Adresa: record — of ( 


Facultăţi; 


Biblioteci: set-of(í 


Profil: string 
Bibliotecari: set - of ( 
-of( 
Nume: siring 
Studii: string) 


Fig. 7.4. Exemplu de definire de tip de obiect complex 


Asociind valori compatibile cu definirea tipului, situația ar putea apare de forma: 
IL: ['ASE", "Bürbulescu', ['Bucureşti’, 'Piaja Romană’, '6] 


['CSIE', “Popescu. "Bucureşti, {Informatică '800), ['Cibernetică', 500,2 


['Statistică', '500'], ['Economie', '400')]), 
(['Dorobanţi — 2700'. "Informatica", (["Dan', 'superioare'), ['Vasile'. 'medii'])], 


T'Eminescu — 1000', "Management", (['Barbu', 'superioare '], [ Tudor", 'medii'])])] — 


unde: 
- înregistrările sunt definite prin paranteze drepte iar seturile prin acolade: 
- UI reprezintă o instanţă din cadrul definirii tipului de obiect complex. 
De remarcat faptul că un obiect poate include referiri explicite la un alt obiect, pe 
bază de OID (Object Identifications). Incluzând referiri în structura din figura 7.4., nous. 
definire de tip obiect complex va apare astfel (figura 7.5): 


Universitate: record — of 


Oras: string, 

Strada: string, 

Număr: integer), 
Facultăţi:  set— of (° Facultăţi), 
Biblioteci: set — of (*Biblioteci)) 


Oras: string 
Secţii: set — of (* Secţii) 
(Denumire: string, 


Nr - studenţi: integer), 
(corp = clădire: string, 
Profil: string, 
Bibliotecari: set — of (* Bibliotecari)) 
(nume: string, 
studii: string) 


Fig. 7.5. Exemplu de definire implicând si referinje de obiecte 


Secţii: record- of. 


Biblioteci: record — of 


Bibliotecari: record — of 


Un set de instanțe pentru definirile de mai sus, implicând si referințele la alte obiecte, 
apare astfel (figura 7.6.): 


0l:  «OIDI,  ['ASE', 'Bárbulescu', [' Bucureşti”, "Piaţa Romană”, '6'), OID2, OID7]» 
02: <OID2,  ["CSIE", "Bucuresti', (OID3, OID4, OIDS, OID6)]- 

03: «OID3, ['Informatick", '600']> 

04: i 
05: 


07: «OID7, (OIDS OIDII]- 

08: «OIDS, [Dorobanți -2700", "Informatică", (OID9, OIDI0J], 
1 , ['Dan', 'superioare"] > 

10: «OIDIO, ['Vasile", 'medii']> 

Il: «OIDIL, ['Eminescu', "Management", [OIDI2, OIDI3]], 
E: ['Barbu', "superioare'] > 

13: «OIDI3, ['Tudor', 'medii"] > 


Fig. 7.6. Exemplu de instanţă in care apar şi referiri 
7.64.2. Clase de obiecte 


Multitudinea obiectelor ce se bucură de aceleaşi proprietăţi și comportament 
formează o clasă de obiecte. 

Obiectele din cadrul unei clase constituie instanfieri ai clasei respective. În UML o 
clasă se reprezintă printr-un dreptunghi cu trei compartimente separate prin linii orizontale: 
numele clasei în primul compartiment, lista de atribute în al doilea compartiment și lista de 
operaţii în al treilea compartiment. 

Diagrama claselor indică structura statică a modelului orientat obiect, surprinzând 
Clasele componente şi relaţiile dintre acestea. În figura 7.7. sunt reprezentate clasele 
STUDENT şi CURS. 

O diagramă de obiecte este un graf de instanțe compatibile cu o diagramă de clase 
dă. Într-o diagramă de obiecte, un obiect este reprezentat de un dreptunghi cu două 
compartimente. Numele obiectului este dat sub forma nume obiect: nume_clasa, unde 
ume obiect poate lipsi. 


Fig. 7.7. Exemplu de clase 


.. În figura 7.8. este reprezentată diagrama de obiecte asociată diagramei claselor de 
mai sus. 


- Data Nastere = 23-03-1981 
- Adresă = Bd. Magheru nr.5 
- Telefon 74646306 


Fig. 7.8. Exemplu de instanje 


Clasele joacă același rol în CODM (Conceptual Object Data Model) ca şi relaţiile în 
baze de date relationale (BRD), În modelul relational baza de date este formată dintr-un set 
de relaţii si fiecare relaţie include un set de tupluri iar in CODM o bază de date este formată 
dintr-un set de clase şi fiecare clasă include un set de obiecte. Aşadar în BDR putem avea o 
relație numită STUDENT cu tupluri conținând informaţii despre fiecare student iar in 
CODM pem avea o clasă STUDENT cu obiecte conținând informaţii despre fiecare 
student. Într-o astfel de situaţie apare posibilitatea convertirii unei baze de date relafionale 
într-o bază de date orientată obiect cu atașarea unui OID fiecărui tuplu si invers. 

O clasă are un tip, care descrie structura comună a tuturor obiectelor ce fac parte din 
aceiaşi clasă, şi semnături de metode, care sunt declaraţii de operaţii ce pot fi aplicate clasei 
de obiecte. De remarcat faptul că numai semnăturile metodelor sunt parte a CODM, 
implementările nu sunt. Implementarea unei metode este o procedură scrisă într-un limbaj 
gazdă, ce este memorată pe serverul bazei de date. 

Multitudinea obiectelor ce aparţin unei clase formează un set de obiecte si constituie 
extensia (extent) clasei [24,34,42]. 

Într-un astfel de context, prin analogie, se poate spune că o clasă are rolul de 
container de obiecte în / din care obiectele în mod dinamic pot fi adăugate sau şterse. 

În limbajele de definire a datelor (DDL) ex. în O2 definirile tipurilor sunt incluse ca 
parte a definirilor claselor de obiecte. 

În general, definirea unei clase este separată în două părți, şi anume, partea de 
interfaţă si partea de implementare. 

- interfața descrie tipul obiectelor aparținând clasei, care include semnăturile 
tuturor metodelor, Fiecare semnătură conţine denumirea şi tipul fiecărui 
parametru a metodei. Parametrii de intrare / ieşire în / din metodă fac posibilă 
invocare metodei în cadrul programelor de aplicaţii. 

- implementarea descrie implementarea metodelor adică, transpunerea operaţiilor 
într-un limbaj de programare. 
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Interfața descrie numai operaţiile aplicabile asupra obiectelor în timp ce 
area ascunde programul corespunzător operaţiilor. De remarcat faptul că unele 
SGDBOO oferă posibilitatea abaterii de la interpretarea strictă a încapsulării permiţând 
accesul de date şi prin alte forme / interfețe și nu numai prin intermediul metodelor, de 
exemplu utilizând limbajul de cereri. 4 
Din cele prezentate se poate desprinde ideea că tipurile sunt abstractizări ce permit 
sát descrierea proprietăţilor (stărilor) cât şi comportamentul, în timp ce clasele descriu atât 
- partea extensională a obiectelor cât şi implementarea metodelor referitoare la un tip. Tipul 
descrie proprietăţile abstracte în timp ce clasa descrie implementarea acelor proprietăţi 
abstracte utilizând structuri de date şi programe. 
E Asa după cum s-a mai arătat si in paragrafele anterioare, unii autori de SGBDOO sau 
de cărți folosesc cu precădere conceptul de clasă, alții conceptul de tip iar alţii utilizează 
“ambele concepte, ele fiind înrudite însă distincte. Paolo Atzeni, Stefano Ceri, Ricardo 
Torlone, Michael Kifer şi Arthur Bernstein, se situează pe o astfel de poziţie [65,69,67], 
“precizând că: 
- tipurile şi clasele sunt concepte distincte; 
- fiecare clasă este asociată la un singur tip; 


conceptul de clasă descrie atât implementarea cât şi extensia unui tip; 
clasele ajută la organizarea obiectelor într-o categorie. " v y 
În figura 7.9 se sugerează relațiile între clasă, tip, obiect, valori, extensie, intensie etc. 


e = SM pa ee T Be AL. 
conţine a MES 
un set de pe Ie descriere / atribute 


Obiecte n ——— t e. Valori 


Fig. 7.9. Relaţia între clasă şi tip 


Din figura 7.9 se poate desprinde concluzia că tipul, clasa, extensia şi intensia sunt 
înrudite însă diferite ca noţiuni şi semnificaţie. Fiecare obiect are valori, asociate unor 
atribute ce aparținând unui tip. Fiecare obiect aparține unei clase care are un tip. —— 

În cele ce urmează vom exemplifica modul de descriere a claselor de obiecte ce 
includ şi definirile de tipuri. În acest scop vom face referiri la clasele, tipurile şi conceptele 
edate în figurile 7.3., 7.4., 7.6 folosind limbajul O2, astfel : 


add class Universitate 
hype tuplu (Denumire: string, 
Nume — rector: string 
Adresa: tuplu (Oraş: string, 
Strada: string, 
Număr: integer) 
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Facultăţi: set — of (*Facultáfi), 
Biblioteci: set — of (*Biblioteci)) 
add class Facultăţi 
type tuplu (Denumire: string, 
Nume — decan: string 
Oraş: string 
Secţii: set — of (* secţii) 
add class Secţii 
type tuplu (Denumire: string, 
Nr — studenţi: integer) 
add class Biblioteci 
type tuplu. (Corp - clădire: string, 
Profil: string, ^ 
Bibliotecari: set — of (* Bibliotecari)) 
add class Bibliotecari 
type tuplu. (nume: string, 
studii: string) i 
De remarcat faptul că în O2 avem de a face, pe de o parte, cu schema bazei de date, - 
care include definirea proprietăţilor şi metodelor claselor, iar pe de altă parte cu baza de dale - 
propriu-zisă ce include datele efective. In acest context prin comanda " add " se adaugă o | 
clasă la schema bazei de date, presupusă că a fost declarată anterior. 


7.6.5. Metode — - Ay 


7.6.5.1. Conceptul de metodă şi aspecte de ordin general 


Aşa după cum s-a mai precizat, multitudinea operaţiilor pe care le poate efectua un | 
obiect sau se efectuează asupra acelui obiect implementate într-un limbaj de programare | 
poartă denumirea de metode. $ 
O metodă are o semnătură, care descrie parametrii metodei şi include toate | 
informaţiile ce permit invocarea acesteia sí o implementare, care conţine codul metodei ^ 
(programul corespunzător. metodei), elaborat într-un limbaj de programare. Semnătura f 
metodei este o componentă a definirii clasei de obiecte. 3 
În fiecare metodă este asociată unei clase specifice de obiecte. În acest caz, 
PE a etapa see ha n ete T 
g 


metode multi-fintá (multi-target), care se aplică la un număr arbitrar de obiecte fără a 
favoriza vreunul într-un anumit mod. În acest caz, definirea acestora este dată în mod separat. 
de definirea clasei. Totodată, precizăm faptul că fiecare metodă are un număr arbitrar de. 
parametrii de intrare şi un singur parametru de ieşire. 
Metodele corespunzătoare operațiilor pe care le implementează pot fi grupate astfel: 
- metode constructor (operaţii de tip constructor), destinate a crea o nouă instanţă, 
un nou obiect al clasei. De exemplu, în clasa Student putem avea metoda 
(operația) CREAZĂ-STUDENT care creează un nou obiect de tip student şi îi 
inițiază starea. De remarcat faptul că toate clasele trebuie să aibă o metodă 
constructor; 
- metode destructor, folosite pentru ştergerea / abandonarea obiectelor şi posibil 
altor obiecte legate de acestea; 


- metode de regăsire / accesare folosite numai pentru preluarea valorilor asociate 
atributelor obiectului. Exemplu: pentu clasa STUDENT, metoda 
CALCULEAZĂ-VÂRSTA studentului plecând de la data naşterii sale. O astfel 
de metodă nu afectează starea obiectului; 

- metode de actualizare, folosite pentru actualizarea stării obiectului. Exemplu, 
metoda posibilă schimbă — adresa din clasa student are menirea de a actualiza / 
modifica valoarea atributului adresa. 


Metodele mai pot fi clasificate şi în funcție de specificul cerințelor de aplicaţii, astfel: 

- metode publice, ce reprezintă particularitatea că pot fi apelate din oricare program 
de aplicaţie; 

- metode private, ce prezintă particularitatea că pot fi apelate numai din interiorul 
altor metode ale aceleași clase. 


7.6.5.2. Definirea semnăturilor şi implementarea metodelor 


În cele ce urmează vom recurge la un exemplu de definire de semnătură și 
implementare a unei metode in O2. Totodată, reamintim că o bază de date O2 este formată 
din două componente şi anume: schema bazei şi baza de date propriu-zisă. Schema conţine 
informaţii despre structura de date a fiecărei clase, atributele si metodele ci, drepturi si 
privilegii de acces etc. Baza conține date actuale în concordanță cu schema. 

Procedura de lucru cu O2 prevede pentru început crearea schemei. bazei de date, de 
forma: - 

CREATE SCHEMĂ - denumire — schema; 
CREATE BASE denumire — bază; 
apoi activarea schemei si bazei, de forma: 

SET SCHEMĂ denumire — schema; 

SET BASE denumire — bază; 

După aceste operații se poate trece la definirea claselor şi metodelor corespunzătoare 
Schemei setate. Ulterior pot fi făcute noi adăugări de clase de obiecte. 

Presupunem ca dorim să adăugăm o metodă “inir” schemei bazei în care este inclusă 
Clasa Universitate, din figura 7.3. Definirea semnăturii metodei va apare astfel: 


add method înit (Denumire — par: string, 
Nume — rector — par: string, 


string, 
Număr — par: integer) 
in Class Universitate is public 
iar definirea implementării metodei "init" implică următoarea sintaxă: 
Body method init (Denumire — par: string, 
Nume — rector — par: string, 
Oraş — par: string, 
Strada — par: string, 
Număr — par: integer) 
in Class Universitate 
CO2 (self — Denumire = Denumire — par; 
self — Nume = Nume — par; 


self —> Oraş = Oraş — par; 
self — Strada = strada — par; 
self — Număr = Număr — par; 
return (Self);)$ 


Referitor la definirea semnăturilor si implementării metodelor, în cele ce urmează 
vom căuta să facem anumite precizări. 

Metoda init face parte face parte din categoria metodelor constructor (de creare) de 
clasă; ea generează partea de stare a unui nou obiect creat în cadrul clasei Universitate, 

Structura de definire a semnăturii apare astfel: 


Method den-metodă (p,, pyy.. 


unde: 
- partea mai pronunțată reprezintă cuvinte rezervate; 
7 Bass Pa reprezintă parametrii actuali de apel, 


În ceca ce priveşte partea de implementare a metodei, ea este precizată pri cuvântul 
rezervat "body" şi este scrisă în CO2 (o extensie a limbajului de ERN C cie permite 
accesul direct şi transparent la obiectele stocate in baza de date, La nivelul corpului metodei 
(body init) se precizează lista de parametrii, conform următoarei sintaxe: 

Body denn-metodă (d,.d,,..., d, ) in class den-clas& 
unde: 

~ partea mai pronunțată reprezintă cuvinte rezervate; 

7. d, d;,..., d, reprezintă lista de parametrii formali de comunicare. 

„Implementarea este inclusă într-un bloc de iniţializare delimitat de cuvântul cheie 

CO2 si terminat cu simbolul $. 

Cuvântul "self" are semnificaţia de variabilă de adresă ce indică obiectul clasei țintă 
la care metoda se aplică. Cu alte cuvinte, invocarea unei metode pe un obiect dat este 
similară cu trimiterea unui mesaj la acel object; "se//” indicând obiectul primitor, adică 
obiectul ce va primi mesajul. 

, ,., Simbolul "—" este echivalent cu semnificaţia punctului (+) folosit frecvent şi în alte 
limbaje de programare în scopul de a face o calificare de atribut/câmp, cu ocazia unei 
anumite referire la acel atribut. Exemplul: 

self — Nume-persoană = Nume-paremetru 
echivalează cu descrierea de forma: 

self * Nume-persoană = Nume-parametru 
unde atributul / câmpul Nume-persoană de la variabila self este inifializat cu o valoare dată 
de atributul / câmpul Nume-parametru. 


3 Urmărind cele două aspecte referitoare la metode şi anume, semnătura şi 
implementarea metodei, observăm că ambele presupun precizarea unei liste de parametri. Cu 
privire la cele două liste de parametri p, si d, se pot face anumite precizări, astfel: 
- parametrii p, poartă denumirea de parametri efectivi sau actuali, respectiv 
parametri d, poartă denumirea de parametrii formali; 
- ai dintre parametri efectivi şi formali pot avea semnificaţia de paramerri de 
e pentru metodă, iar, o parte pot fi parametrii de ieşire prin care metoda 
returnează rezultatele; bi 
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- cele două liste oferă suportul pentru asigurarea comunicării între semnătură şi 
implementare, în sensul că prin listele de parametrii se transfera datele (valorile) 
solicitate de metodă; 

- corespondența dintre parametrii pi -12,...,n $i di - 12,..., n, se face prin 
locul ocupat în lista de parametri si nu prin numerele lor; într-o astfel de situaţie 
denumirile parametrilor p, şi d, pot să coincidă sau să difere, însă numărul 
parametrilor în cele două liste, precum şi tipul lor trebuie să fie același. 
Necesitatea acestei identități rezultă din faptul că numai parametrilor 
pol =1,2,..-n li se rezervă memorie, parametrii d, utilizează aceleaşi zone de 

: memorie ca si p,. 


Invocarea metodei init, într-un program scris in CO2 apare astfel: 
execute CO2 
(02 Universitate X; 
X = new (Universitate); 
[X init ("ASE", “Roşca”, " Bucuregti", “Romană”, 1)];)$ 


- execute CO2 marchează lansarea în execuţie a metodei init; 

- pentru declararea variabilelor locale se foloseşte cuvântul cheie "CO2"; 

- linia a doua de program defineşte o variabilă locală cu denumirea X si un tip 
Universitate; 

- linia a treia definește instrucţiunea de crearea a unui obiect ce aparține clasei 
Universitate, invocând totodată metoda new, metodă valabilă tuturor claselor 
pentru crearea unui nou obiect si inserarea acestuia într-o clasă 
corespunzătoare; 

- instrucțiunea de pe linia finală a metodei init aplicată la acel obiect, atribuie 
valori iniţiale proprietăţilor obiectului nou creat. Se poate observa cà în 
apelarea metodei se indică obiectul țintă şi numele metodei, urmată de o listă 
de valori actuale ale parametrilor de intrare. 

La sfârşitul execuţiei metodei, obiectul pentru care metoda însăși este invocată este 
returnat ca un parametru de ieşire. 

De remarcat faptul că în cadrul unei metode poate fi invocată şi o alta metodă, 
existând astfel posibilitatea de a se genera invocări de lanțuri de metode, cu precizarea că nu 
este permis ca o metodă să se invoce pe sine însăşi în mod direct sau indirect. 


7.6.5.3. Considerente de ordin practic cu privire la proiectarea metodelor 


Unul dintre principalele avantaje ale programării orientate obiect îl constituie 
posibilitatea reutilizării în mod facil a anumitor părți sau componente software. Dacă 
metodele -vor fi definite /proiectate cu mare grijă, atunci părți de programe sau programe 
întregi vor fi concepute o singură dată, însă vor putea fi incluse în metode şi apoi folosite de 
diverse aplicaţii. Pentru a proiecta astfel de metode este de dorit să se țină seama de o serie 
de considerente de ordin practic [71,81,22], cum ar fi: 

- Metodele trebuie să fie scurte; ele nu trebuie să depăşească circa două pagini de 
text. Metodele mai lungi este de preferat să fie descompuse; 

- Metodele trebuie să fie coerente şi consecvente în folosirea notaţiilor sau a unui 
stil comun de definire a denumirilor de variabile; 
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- Metodele trebuie să constituie cerinţe anticipate po viitoarele aplicaţii şi chiar 
mai mult decât atât, ele nu trebuie să se limiteze la 


acceptate ca parametrii, evitând folosirea variabilelor globale; 
- Moștenirea va fi folosită cát mai mult posibil. Este de preferat ca metodele să fie 


definite în superclase şi refolosite în subclase de obiecte. 


7.6.6. Încapsularea și interfața 


T" 


Operatiile formează interfața clasei pentru ca prin intermediul ei clasa își expune ` 
altor clase funcționalitatea fără să igi dezvăluie structura. Această tehnică de ascundere a — 
detaliilor de implementare a unui obiect poartă numele de încapsulare. Se ascunde atât 
structura care memorează datele cât şi implementarea operaţiilor. Deci, pentru un utilizator 
oarecare clasa de obiecte, sub aspectul conţinutului informaţional, apare ca o cutie neagră. P 
Utilizatorii au acces la date prin interfețe sau mesaje. Interfața nu este nimic altceva decât un 
mesaj / stimul prin care se citează denumirea unei metode dintre multiplele metode ale unei. 
clase de obiecte. Deci, operații care arată numai ceea ce face obiectul, nu şi cum face. 

Denumirea unei metode reprezintă tocmai denumirea unei proceduri elaborate într-un 
limbaj de programare oarecare. Prin citarea denumirii metodei va fi lansat în execuție 
programul care în derularea lui va accesa datele conform structurii clasei de obiecte, figura = 
7.10. 


Asupra metodelor si atributelor unei clase de obiecte pot fi instituite anumite restricţii, 
de acces la ele, care mai poartă denumirea de restrictii de vizibilitate, În funcţie de modul de 
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Forma protejată (PROTECTED), notată cu simbolul (4), restricfioneaz& doar parțial 
vizibilitatea. Atributele şi metodele protejate sunt vizibile atât din interiorul clasei în care se 
definesc cât si din toate celelalte subclase ce-i aparțin. 

Precizăm si faptul că, o metodă invocată poate invoca la rândul ci o altă metodă 
dintr-o altă clasă, deci apeluri in cascadă. Situaţia este similară cu lucrul cu programe 
principale si apelări de subprograme de tip Procedură sau Funcție, din alte limbaje de 
programare. 


7.6.7. Polimorfismul 


Polimorfismul presupune faptul că un același mesaj poate fi adresat uneia sau mai 
multor clase de obiecte primind răspunsuri diferite, cu semnificaţii diferite. Exemplu, 
presupunem drept mesaj comanda PRINT, din meniul de sistem. Ea va avea ca efect 
imprimarea unci figuri geometrice dacă se adresează unui fişier (prin analogie clase) de 
figuri; va imprima un text preselectat dintr-un fişier de tip text etc, 


7.6.8. Asocierile intre clase 


Legătura este o conexiune între obiecte. Asocierea reprezintă descrierea unui grup de 
legături cu aceiași Structură şi semantică. Legăturile sunt abstractizate în asocieri asa cum 
obiectele sunt abstractizate în clase. Deoarece legăturile dintre obiecte sunt instanțe ale 
asocierii dintre două clase, este util să se modeleze asocierile dintre clase si nu legăturile 
dintre obiectele acestora. 

Asocierile prezintă o serie de caracteristici, astfel: 


Denumirea asocierii. O asociere dintre două clase este reprezentată printr-o linie care 
conectează două clase (fig. 7.11). Denumirea asocierii, este de regulă un verb care se 
trece deasupra liniei, indicând semnificaţia asocierii, iar prin săgeți se precizează sensul 
asocierii. Denumirea trebuie să fie cât mai sugestivă. 


Fig. 7.11. Reprezentarea asocierii 


În cele ce urmează vom enumera câteva exemplificări de verbe ce pot indica 
asocierea între clase de obiecte. 


Categorie de verb. Exemple de asociere 
Ae parte fizică din B salā curs -corp cldire 

i B elev - clasă / sală 
B sală = orar 
B pagină web - pagină web — Hotel 
B articol - comandă 
B jucător - echipă 
B atelier - secţie 


A este subaltern a lui B angajat - manager 
A conduce B şofer - maşină 

A comunică cu B profesor - student 
A este legat la o tranzacţie B pasager - bilet 

A este o tranzacţie în legătură cu o altă rezervare — - anulare 
tranzacţie 

A aparține lui B autoturism — -proprietar 


Aceste exemplificări ajută în alegerea / definirea cât mai sugestivă a denumirii 
asocierii. 


„Multiplicitatea asocierii. Multiplicitatea reprezintă numărul de instanțe ale unei clase 
care pot avea legături cu o instanță a celeilalte clase dintr-o asociere. Multiplicitatea 
corespunde cardinalit&fii asocierilor în raport cu instanțele claselor. Ea poate fi de mai multe 
feluri şi poate comporta multiple forme de notare. În continuare se redau două dintre acestea. 
Varianta 1 

O instanţă din clasa A are întotdeauna în 
Ll corespondenţă o instanţă din clasa B (unu la 
unm 


91 O instanță din clasa A poste avea O sau | 
A [| poat 
EZ instanțe în corespondenţa din clasa B (unu la 


zero sau unu) 


O instanță din clasa A poate să aibă 0 sau N 
corespondențe de instanțe din B (unu la zero 
sau mai mulți). 4 
L^] hts O instanță din clasa A poate avea 1 sau N 
corespondențe de instanţe din B (unu la unu 
sau mai mulţi) 


Multiplicitatea unei asocieri se exprimă printr-un interval de valori de forma (x,y) 
unde x reprezintă valoare minimă, iar y valoarea maximă. 


Exemple: 

Legătura de tipul "unu la unu". Specificul legăturilor de tipul "unu la unu” constă în 
faptul că fiecare instanţă are în corespondenţă obligatoriu o altă instanță din clasa cu care 
întră în asociere. 
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á 
au Eco 


este primar la 


E LOCALITATE Li 


Sugerează faptul că o localitate poate avea unul si numai un singur primar, iar în sens 
T invers o persoană poate fi primar la una si numai la o localitate. 


Legătura de tipul "unu la zero sau unu”. Specificul acestui tip de legătură constă în 
faptul că o instanță din clasa A poate avea sau nu corespondenţă unei instanțe din clasa B. 


este înscrisă în 0,1 
m 
500,* dee 


Sugerează faptul cà un partid politic poate avea minim 500 de persoane sau mai 
multe, însă o persoană poate să nu facă parte din nici un partid, sau să facă parte din cel mult 


un partid. 
Legătura de tipul "unu la zero sau mai mulţi” 


are înscrişi [^d 
[ cns racuLzarn ] Bin) Od» 
j urmează 


O altfel de legătură exprimă faptul că la un curs facultativ poate să nu fie înscris nici 
un student sau pot să fie mai mulţi studenţi pentru frecventare. 


hz suae 


m 


Legătura de tipul "mulţi la multi" 


sunt furnizate de 1,» 
MATERII _PRIME = FURNIZORI 
meu 


Legătura de tipul "mulţi la mulți” de mai sus exprimă faptul că un material poate fi 
livrat de unul sau mai mulți furnizori, iar un furnizor poate livra unul sau mai multe 
materiale. an 

O multiplicitate de forma (2,5) semnifică faptul că la realizarea legăturii pot participa 
minim 2 şi maxim 5 instanțe dintr-o clasă de obiecte. Când limita superioară a intervalului 
este „„+” înseamnă că avem de-a face cu o limită superioară infinită. 
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Varianta 2 


O instanţă din clasa A are în corespondență o 
instanţă din clasa B (unu la unu) 


O instanță din clasa A poate avea O sau 1 
instanțe în corespondenţa din clasa B (unu la — 
zero sau unu) 


O instanţă din clasa A poate să aibă 0 sau N 
corespondenje de instanțe din B (unu la zero — 
sau mai mulţi). i 


O instanţă din clasa A poate avea 1 sau N 
corespondențe de instanțe din B (unu la unu 
sau mai mulţi) = 
O instanță din clasa A poate avea în 
corespondenţă exact 5 instanţe din B 

O instanţă din clsa A poate avea în 
corepondenţă exact 3, 5 sau 8 instanţe din 
clasa B 


Tipul asocierii. Tipul asocierii este dat de numărul claselor participante la o asociere 
există mai multe tipuri de asocieri: unare, binare, ternare ş.a.m.d. Acestea pot fi notate astfel: 


Asocierea unară, presupune faptul că a o clasă de obiecte intră în asociere cu a 
însăși. O astfel de asociere este recursivă. 


l ret ipd Presupunem o clasă numită PERSOANE, la nivelul unei societăţi - 
comerciale. În cadrul acestei clase poate fi definită o asociere cu denumirea CĂSĂTORIE, 
astfel încât să se poată da răspuns la o întrebare de genul „Care sunt persoanele soţ — soţie ce | 
lucrează în aceeaşi societate comercială?” O astfel de asociere este redată in figura 7.12. 


Baze de date orientate obiect 


angajat în 


: [mra 


Fig. 7.13. Exemplu de asociere binară 


are 


Interpretarea asocierii din figura 7.13 apare astfel: un salariat poate fi angajat cel 


putin într-un departament şi cel mult într-un departament. În sens invers, într-un departament 
pot lucra unul sau mai mulți salariaţi. 


Asocierea ternară, presupune existenţa a trei clase de obiecte. În figura 7.14 se 
prezintă forma generică a unei astfel de asocieri. 


Nume clasă 2 


Fig. 7.14. Exemplu general de asociere ternară 


Un exemplu pentru reliefarea asocierii ternare este prezentat în figura7.15 


Fig. 7.15 Exemplu concret de asociere ternară 


Asocierea „Împrumută” este o asociere între trei clase: Client, Bancă şi Investiţie, 
banca acordând împrumutul unui client pentru o anumită investiţie. Se observă că asocierea 
„Împrumută” nu poate fi divizată în asocieri între două clase fără a pierde din informatie. 


Rolul clasei în cadrul asocierii. Prin rol se indică semnificaţia fiecărei clase în cadrul 
asocierii. Numele de rol este un concept prin care se identifică în mod unic capetele unei 
asocieri. O clasă, care are mai mult de o asociere, poate juca roluri diferite faţă de fiecare 
dintre acestea. 


Nume 
Data Naştere 
Vârsta 


Fig. 7.18. Reprezentarea unui atribut derivat 


În figura 7.18. atributul Vârsta este un atribut derivat al clasei Student, întrucât se 

Fig. 7.16. Evidenfierea rolului fi cas [geo eekcultposbed vinta eot Dus Nee și dea cuti 

1 Atribut al clasei. Obiectele se diferențiază între ele prin valorile pe care le iau 

` atributele lor la un moment dat, valori care constituie starea obiectului în acel moment. O 
categorie specială de atribute sunt "atributele clasei”. 

5 Un atribut al clasei reprezintă un atribut a cărui valoare este comună clasei de obiecte 
“şi nu unei instanțe specifice. Simbolul folosit pentru acest tip atribut este caracterul ”$” 
plasat în fata denumirii atributului, așa cum se poate observa în figura 7.19 


În figura 7.16 se poate observa că un utilaj, din punct de vedere al băncii, poate 
reprezenta o garanție, în timp ce din punct de vedere al firmei, el reprezintă un mijloc de 
producție, Numele de rol se reprezintă prin intermediul unei etichete atașată capătului 
asocierii. Firma are rolul de proprietar de utilaj. 


Atribute şi clase ale asocierii. Când o asociere are atribute si operații proprii, sau 
când participă la asocieri cu alte clase, asocierea se modelează ca o clasă şi poartă numele de 
clasă a asocierii (figura 7.17). 

„Asocierea dintre clasele Împrumut si Banca este caracterizată de următoarele 
atribute: suma împrumutată, data acordării împrumutului, data rambursării împrumutului. 
dobândă si operaţia de rambursare împrumut, Toate aceste atribute şi operaţii sunt at i 
operaţii ale asocierii si vor fi reunite în clasa Împrumut; ele nu aparțin în totalitate ni 
Client si nici clasei Banca ci aparţin ambelor clase. 


Fig. 7.19. Atribut al clasei 


Clasa Factura, pe lângă atributele specifice unei facturi cum ar fi data emiterii, 
valoare fără TVA, TVA, valoare cu TVA etc., are şi atributul NrTotalFacturi care este o 
caracteristică a clasei şi nu a instanței. 


Ordonare. În cazul unei asocieri în care la unul din capete se specifica „mulți”, setul 
de obiecte poate să nu fie ordonat (fiind ca un set de obiecte), sau poate fi ordonat explicit. 
Mesajul ordonării în cazul când acest lucru este important, se face prin menţiunea {ordered} 
lângă semnul care indică multiplicitatea. Ordonarea este un tip special de constrângere 
aplicabil asocierilor. Să luăm exemplul alcătuit din clasele Ghişeu şi Persoană (figura 7.20). 


Fig. 7.17. Exemplu de asociere cu atribute si operaţii 


Atribut derivat. Un atribut derivat este un atribut care poate fi calculat sau derivat 
plecând de la alte atribute. Un astfel de atribut se reprezintă grafic prin simbolul "/^ pus în 
fata denumirii acestuia. 


Fig. 7.20. Ordonarca într-o asociere 


„ Calificarea. Numim asociere calificată o asociere, care leagă două clase, şi un 
calificator, care are rolul de a reduce multiplicitatea efectivă a unei asocieri. Asocierile de 
tipul „unul la mulți” şi „mulţi la mulţi” trebuie să fie calificate. Calificarea permite ca din 

- multitudinea de obiecte aflate la capătul ,,multi" al asocierii să sc identifice unic un anumit 
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obiect. Considerând exemplul alcătuit din clasele Furnizor şi Contracte şi asocierea încheie, 
vom aveam o relaţie „unu Ja mulți”; un fumizor încheie unul sau mai multe contracte iar un 
contract nu poate fi încheiat decât cu un singur furnizor. Calificatorul cod furnizor permite 
reducerea asocierii „unu la mulți” la o asociere „unu la unu”, întrucât un furnizor şi un 
număr de contract permit identificarea unică a unui furnizor (figura 7.21): 


Baze de date orientate obiect 


încheie 1 
[sn emm 
[PEL D 4e sul pue Te 
1 încheiat 


Cod fimizm | CONTRACTE 


Fig. 7.21. Calificarea asocierii 


ci 


. Mostenirea 


Mostenirea este un mecanism ce dă posibilitatea partajárii atributelor şi operațiilor 
utilizând relaţia de generalizare. Moștenirea poate fi redată astfel: (figura 7.22. 


cu semnificaţia că o clasă B moşteneşte de la o 
altă clasă A proprietăţile si comportamentul 


Fig. 7.22. Moștenirea 


Moștenirea poate fi simplă sau multipla. Moștenirea simplă presupune faptul că o 


subclasá B moşteneşte proprietăţile si comportamentul doar de la o singură superclasă A 
(este cazul din figura 7.22.). , se să 
Mostenirea multiplă presupune faptul că o subclasá B poate moşteni proprietăţile şi 
comportamentul de la două sau mai multe superclase, asa după cum reiese din figura 7.23. 
^^ Se observă că subclasa E moștenește proprietățile şi comportamentul atât de la 
superclasa A cát şi de la B. Clasele constituite special pentru a fi moştenite se numesc clase 
abstracte şi acestea nu au instanţe, iar numele lor se scrie cu format cursiv (italic ).0 clasă 
construită pentru a crea instanţe se numeşte clasă concretă. Clasele abstracte conțin cel puţin 
o operaţie abstractă, adică o operaţie neimplementată si care urmează să fie implementată în 
clasele descendente. P - 
Mostenirea oferă marele avantaj cu privire la reutilizarea „codului” si definirea de 
ierarhii de clase. În acest mod sporeşte considerabil de mult productivitatea muncii în 
activitatea de programare. 


` 
5 


Fig. 7.23 Exemplu de moştenire multiplă 


7.6.10. Generalizarea şi specializarea 


Generalizarea şi specializarea sunt mecanisme care permit partajarea caracteristicilor 
comune între clase, păstrând totodată diferenţele dintre acestea. Generalizarea presupune 
identificarea atributelor şi/sau operaţiilor comune mai multor clase $i izolarea lor în 
superclase. Specializarea claselor este opusă generalizării si are ca punct de plecare o 
superelasă ce urmează a fi descompusa in subclase si la care se pot adaugă noi atribute și/sau 
operaţii relevante numai pentru anumite obiecte din acea clasă, creând astfel subclase de 
obiecte. Atributele si operațiile superclasei nu mai apar în cadrul subclaselor atașate ei, dar 
ele aparțin acestora prin moştenire. În subclase se descriu numai atributele şi/sau operațiile 
specifice fiecăruia dintre ele. Subclasa rafinează, specializează clasa. Superclasele şi 
subclasele se mai numesc părinți / copii sau strămoși / descendenti. În figura 7.24 se prezintă 
operațiile de generalizare si specializare, 

Un alt exemplu extrem de sugestiv l-ar putea constitui mulțimea studenţilor din 
cadrul unei universităţi. Studenţii ar putea fi priviţi ca formând o singură colectivitate (clasă) 
ia nivelul întregii universităţi şi apoi pe subcolectivităţi (subclase) în funcție de specializarea 
urmată (facultăţi si secții), deci subclase, ca în figura 7.25. 

STUDENTI-ASE apare ca o superclasă ce conține proprietăţile şi comportamentul 
comun tuturor studenţilor, apoi la nivelul fiecărei subclase se precizează doar ceea ce îi este 
specific fiecărei subclase şi care permite diferențierea subclaselor. 

Se poate deduce faptul cà pentru generalizare se pleacă de la niște clase deja 
existente, din care vor fi desprinse aspectele comune claselor, definind cu acestea o 
superclasă, iar specializarea presupune existența unei singure clase din care vor fi desprinse 


3 De remarcat faptul că generalizarea se implementează prin relaţia de moştenire însă 
în cadrul limbajelor de programare orientate obiect, ea capătă un aspect mai abstract. 
vantajele utilizării generalizării sunt următoarele: 
- Reutilizarea codului — în proiectul în lucru pot fi folosite clase create în cadrul 
altor proiecte; 
~ Standardizarea — aspectele comune sunt specificate o singură dată; 
~ Calitatea superioară — reutilizarea claselor create pentru alte proiecte presupune și 
faptul că ele au fost testate deja în cadrul acelor proiecte. 


Fig. 7.24. Generalizarea si specializarea 


STUDENŢI - ASE 


STATISTICĂ 


INFORMATICĂ CIBERNETICĂ 


Fig. 7.25. Exemplu 2 de generalizare/specializare 


7.6.11. Agregarea, compunerea si descompunerea 


Agregarea şi descompunerea sunt operaţii care permit reprezentarea relaţiilor de tipul 
parte-întreg dintre obiecte. Agregarea descrie un obiect ca fiind constituit din mai multe 
obiecte. De asemenea, agregarea se foloseşte la gruparea claselor într-o nouă clasă. Ea este 
folosită la construcţia unui obiect complex prin compunerea lui din părțile componente. 
Agregarea este un tip special de asociere între o clasă "întreg” si una sau mai multe clase 
parte" (figura 7.26.). 
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Fig. 7.26. Agregare, descompunere 


Agregarea şi compunerea se reprezintă grafic prin intermediul unui romb, Un romb 
plin semnifică o relație de compunere. Într-o relație de compunere, spre deosebire de relația 
de agregare, obiectul parte aparține unui singur obiect întreg, de exemplu, o cameră este 
parte a unei singure clădiri, din această cauză multiplicitatea părții întreg dintr-o astfel de 
relaţie este întotdeauna 1. Un alt exemplu de agregare si descompunere este redat în figura 
1217. 


Agregare Explozie 


| CARBURATOR | CILINDRII 


Implozie Descompunere 


Fig. 7.27. Exemplu de agregare şi descompunere 
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7.7. Standardul ODMG pentru baze de date 
orientate obiect 


7.7.1. Aspecte generale referitoare la standardizare 


În condiţiile exploziei informaţionale cu privire la abordarea obiectuală în domeniul 
informaticii, pentru a veni in sprijinul realizatorilor şi utilizatorilor de astfel de produse 
software şi hardware s-a conturat din ce în ce mai mult preocuparea pentru elaborarea unor. 
standarde în acest domeniu de interes. Astfel, în 1989 s-a format OMG (Object Management 
Group) ca un consorțiu non-profit având ca principal scop promovarea orientării spre obiecte 
în ingineria programării şi dezvoltarea de standarde. Grupul reuşeşte peste 700 de unităţi 
membre, ce includ aproape toţi realizatorii de produse software si hardware din lume, cum ar 
fi: Microsoft, ORACLE, IBM, SAP, SUN, Apple, NCR, DEC, Hewlett-Packard, Object 
Design Inc., Objectivity etc. 

De remarcat faptul că OMG nu este un grup sau organizație recunoscută pentru 
standarde aşa cum sunt: Organizaţia Internaţională de Standardizare (ISO), Institutul 
Naţional American pentru Standarde (ANSI) sau Institutul de Inginerie Electrică şi 
Electronică (IEEE) ci Consorţiul OMG face propuneri de Standarde care ulterior sunt 
supuse spre acceptare de ISO sau ANSI. că 

Dintre realizările consorțiului OMG precizăm faptul că în anul 1990 a elaborat si 
publicat o documentaţie intitulată "Object Management Arhitecture Guide”. Ghidul are — 
menirea de a specifica: 

- o terminologie unitară pentru limbaje, sisteme şi baze de date orientate obiect; 

~ un cadru abstract pentru sistemele orientate spre obiecte; 

= un set de scopuri tehnice si arhitecturale; 

- un model de referinţă pentru aplicaţiile distribuite utilizând tehnicile orientării 

spre obiecte. y 

În cadrul modelului de referință pentru aplicații distribuite au fost identificate — 
următoarele domenii ale standardizării: 3 

- modelul de obiecte OM (Object Model); : 

- brockerul de cereri de obiecte ORB (Object Request Brooker), pe baza căruia s-a 

definit Arhitectura brockerului de cereri comune cunoscută sub denumirea de ^ 
CORBA (Common Request Brocker Arhitecture); 

- serviciile de obiecte (memorare, administrarea tranzacţiilor, integrării, realizarea 

versiunilor şi securitatea sistemului); 

- facilităţi comune (help, E-mail şi browser). 


— 


m 


În 1989 câţiva producători de software pentru baze de date s-au reunit si au format un 
grup pentru administrarea bazelor de date orientate obiect ODMG — Object Database . 
Management Grup, având ca obiectiv de a defini standarde pentru SGBDOO. Din cadrul | 
grupului faceau parte producătorii: Gemstone Systems, Object Design, 02 Technology, 
Versant Object Technology, UniSQL, POET Software, Objectivity, IBEX Computing SA, 
Lockheed Martin, Ontos, Servio, Hewlett-Packard, etc. 

Grupul de lucru a conceput un model standard incluzând următoarele componente. 
pentru SGBDOO: 

- modelul de obiecte (OM), 


Baze de date orientate obiect 


limbajul de definire a obiectelor (ODL — Object Definition Language), 
limbajul de interogare a obiectelor (OQL — Object Query Language), 


- interfață cu limbajul C++, 

- interfață cu limbajul Smalltalk, 

- interfață cu limbajul Java. 

Actualmente, sistemele comercializate ce suportă standardul ODMG 3.0 includ 
GemStone  (hitp:/Avww.gemstone.com),  Objectstore — (http//www.odi.com.), Poet 


(ut scpocLoni ete, 
in cele ce urmează ne propunem să facem o trecere în revistă doar a primelor trei 
componente iar pentru celelalte trei recomandăm cititorilor interesați câteva surse mai 


insemnate de documentare (www.odmg). 


7.7.2. Modelul de obiecte 


Modelul ODMG de obiecte reprezintă un superset al modelului OMG de obiecte, 
urmărind în mod deosebit de a asigura portabilitatea proiectării şi implementării aplicaţiilor 
pe diverse SGBDOO care acceptă modelul de obiecte. 

Elementele fundamentale care constituie suportul pentru modelare sunt: 

- Modelul ODMG este bazat pe obiecte, fiecare obiect având un identificator unic; 

- Obiectele pot fi clasificate în tipuri. Multitudinea obiectelor de un tip dat prezintă 

un comportament şi o stare comună; 

- Starea obiectului este dată de valorile pe care le iau proprietăţile obiectului, O 

proprietate poate fi un atribut sau o relaţie dintre unul sau mai multe alte obiecte; 

- Multitudinea operaţiilor pe care le poate efectua un obiect sau alte obiecte asupra 

lui implementate într-un limbaj oarecare de programare poartă denumirea de 
metodă; 

- Miultitudinea metodelor aparţinând unui obiect definesc comportamentul acelui 

obiect; 

- Fiecare metodă este însoţită de o semnătură prin care se precizează denumirea 

operației, denumirea şi tipul tuturor parametrilor de intrarea si ieşire şi situaţii de 
excepţie ce pot interveni (condiţii de eroare); 

- Baza de date ce stochează obiectele în concordanţă cu schema acestuia, descrisă 

cu ajutorul unui limbaj de definirea a obiectelor (ODL). 

Despre toate aceste elemente fundamentale găsim detalii în paragrafele anterioare, 
precum şi alte lucrări de referință [4,19,30,51]. 


1.7.3. Limbajul de definire a obiectelor 


Limbajul de definire a obiectivelor — ODL (Object Definition Language) este destinat 
descrierii schemei bazei de date orientate obiect. El descrie tipuri şi nu clase si este 
independent de limbajul de programare ales pentru implementarea claselor. El defineşte 
Atributele, relaţiile dintre tipuri şi specifică semnătura operaţiilor (metodelor). De reținut 
faptul că el nu se referă la implementarea semnăturilor. ODL a fost conceput de ODMG. 
Sintaxa ODL se bazează pe limbajul de Definire a Interfejei — IDL (Interface Definition 
Language), fiind o extensie a acestuia. IDL aparține OMG-ului si este parte integrantă a lui 
CORBA (Common Object Request Broker). 


pase uc uate Orientale oDiect 


ODMG a ales IDL ca bază de referinţă, în loc de a inventa o nouă sintaxă, pe 


considerentul că prin această alegere se asigură un grad sporit de compatibilitate cu 
recunoscutul şi importantul standard CORBA pentru sisteme de baze de date distribuite. 

Terminologia utilizată în ODL diferă în anumite privinţe de cea utilizată de CODM, 
Această diferență îşi găseşte explicaţia, într-o oarecare măsură, tocmai în obiectivul urmărit 
de ODMG şi anume acela de a asigura o maximizare a portabilităţii schemei de date pentru 
mai multe limbaje de programare. 

Ideea avută în vedere de ODMG constă în faptul că schema bazei de date definită de 
ODL trebuia să permită accesarea obiectelor în mai multe limbaje de programare gazda. 
Acest lucru, pentru moment, este posibil în limbajele C++, Java si Smalltalk. 

În semnificaţia ODMG, pentru fiecare legătură cu limbajele de programare gazdă se 
orele er cal documentaţiei sau adaptarea acesteia în contextul respectării structurii 
comune 


Comunicarea se face printr-un set de variabile din limbajul gazdă şi un preprocesor 
special care modifică cadrul sursă pentru a înlocui afirmaţiile ODL cu apelări la rutinele 
SGBD. Codul sursă poate fi apoi compilat și linkeditat în mod normal. 

Faptul că ODL defineşte tipuri ce pot fi implementate în numeroase limbaje de 
programare oferă numeroase avantaje, astfel: 

- ODL permite ca o aceeași bază de date să fie partajată pe multiple limbaje de 
programare, sau cu alte cuvinte, o aceeași aplicaţie să fie portabilă pe numeroase 
limbaje de programare fără rescrierea definirii schemei bazei de date. 

- ODL este utilizat pentru analiza şi conceperea schemei bazei de date inaintca 
descrierii datelor şi operaţiilor unei aplicaţii independent de un limbaj de 
programare. Concepţia rezultată poate fi utilizată fie în mod direct fie translatată 
într-un limbaj de descriere a datelor ales de programator; 

- Schema descrisă în ODL este acceptată de toate SGBD compatibile cu concepția 
ODMG. 

De remarcat faptul că nu este posibil întotdeauna obținerea unei compatibilităţi de 
100% a schemei bazei de date cu alte produse software, datorită unor diferențieri intrinseci a 
modelelor limbajelor de programare. Deci, ODL va comporta coloratura şi specificul 
limbajului gazdă cu care realizează li 

De exemplu, în cazul legăturii cu Java, ODL distinge două feluri de clase. Prima este 
numită interfa[d iar a doua clasă. Pentru a evita confuzia cu clasele CODM recurge la 
numirea acestora interfaţă ODMG i respectiv clasă ODMG. 

În termenii CODM, definiţia interfeţei si clasei ODMG specifică: 

. un nume de clasă (în sens CODM) împreună cu partea relevantă a ierarhiei de 

moştenire; 

- un tip asociat clasei de referință. 

O colecţie de astfel de definiţii specifică schema întregii baze de date ODMG. 


Principalele diferenţe dintre interfețele ODMG şi clasele ODMG sunt: 

~ O interfață ODMG nu poate include codul (programul) pentru metode; ceea ce 
înseamnă ca sunt permise doar semnăturile metodei, acest aspect constituie 
tocmai motivul pentru care se numeşte interfaţă. Clasele ODMG includ codul 
pentru metodele claselor de referință. Semnătura și codul pot fi explicit 
e Pour Klum n RAD REO i ROCA bet oda ră 
cadrul unei ierarhii de clase de obiecte; 

- O interfaţă ODMG nu poate avea propriile ei obiecte membre, adică instanţele de 
obiecte ale interfeței nu pot fi create. Din contră, o clasă ODMG poate ave? 
obiecte membre; 
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- O interfață ODMG nu poate mosteni dintr-o clasă ODMG dar poate mogteni doar 


din altă interfață ODMG; 


- O clasă ODMG poate mosteni din multiple interfețe ODMG dar nu poate avea 


decât cel mult o superclasă ODMG imediat. 
Distincția dintre clase și interfețe se face din următoarele două considerente: 


În primul rând această distincție face ODL-ul un superset al IDL-ului CORBA, 
prin aceasta asigurând un grad sporit de compatibilitate cu acest important 


standard pentru sisteme distribuite. 


- În al doilea rând această diferenţiere permite ODL-ului să depășească câteva 
dintre problemele asociate cu moştenirea multiplă care apare când o clasă 
moşteneşte două definiri diferite pentru o aceiași metodă din superclase diferite. 


Precizăm faptul că o prezentare completă a sintaxei unui limbaj ODL depăşeşte 
scopul acestei cărţi. Totuşi, următorul exemplu va ilustra unele elemente ale limbajului. 
Cititorului interesat îi recomandăm, pentru o definiție completă a ODL-ului, să consulte [11]. 
Pentru exemplificarea modului de utilizare a ODL ne vom referi la schema parţială 


prezentată în figura 7.3, 
Interface UNIVERSITATE { // Defineste interfaţa pentru 
// entitatea Universitate 
/* Urmează definirea atributelor LA 
atribute string Denumire; 
atribute structure Nume-rector (string nume, string prenume); 
atribute string Oraş: 
atribute string Strada; 


atribute Set < string > Număr-telefon; 
/* Urmează definirea relaţiilor ~ 
relationship BIBLIOTECA are 
inverse BIBLIOTECA:: aparține _de; 
relationship PROFESOR are 
inverse PROFESOR:: este la; 
relationship LABORATOR dispune de 
inverse LABORATOR:: apar(ine. de; 
/* Urmează definirea semnăturilor */ 
Void adaugá, un nou nr. tel (în string Număr-telefon); 


// Defineşte interfaţa pentru 
// entitatea/obiectul Facultăţi 
// care moşteneşte obiectul 

/ Universitate 


H 
Interface FACULTATE: UNIVERSITATE. 


t 
„/a Urmează definirea atributelor/proprietăţilor  */ 


atribute string Denumire; 
atribute string Nume-decan; 
atribute string Oraş 
/* Urmează definirea relaţiilor LA 
relationship Set <Catedră> coordonează 
inverse Catedra :: coordonatá de; 
relationship Laborator foloseşte 
inverse Laborator :: folosit de ; 
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relationship Student urmată_de 
inverse Student :: urmează; 


J 
Interface SECTIE: FACULTATE M Definegte interfaţa pentru 
/ obiectul secţie care 
// moşteneşte obiectul 
M Facultate 
{ 
/* Urmează definirea atributelor/proprietăților LA 
airibute string Denumire; 
atribute string Nume-serii; 
/* Urmează definirea relaţiilor * 
relationship STUDENT specializeazá 
inverse STUDENT :: specialist. in; 
relationship CURS are 
inverse CURS :: se, predà la; 
Interface STUDENT // Defineşte interfața pentru 
//entitate/obiectul STUDENT 
(extent STUDENT); 
Key CNP) 
t 


/* Urmează definirea atributelor +/ 
struct Nume-Prenume (string nume, string prenume); 
atribute Nume-Prenume nume; 
atribute integer CNP; 
atribute integer an-studii; 
atribute string Adresa: 
atribute date Data_de_naștere; 
atribute enum genul ( m, f) sex; 
/* Urmează definirea relaţiilor L4 
relationship FACULTATE urmează 
inverse FACULTATE:: urmată_de; 
relationship SECȚIE specialist in 
inverse SECTIE:: specializează; 
relationship CURS frecventează 
Inverse CURS:: frecventat _de; 
/* Urmează definirea operaţiilor — «/ 
inscrie la curs la secţia (in CURS, in SECȚIE) raises; 
(cerere_nesatisfăcută, curs, plin, nr. locuri ocupate); 
Void transfer. student (in from: SECTIE, in to: 
SECȚIE) raises (nu existà locuri, disponibile); 


A 
Interface CURS // Definegte interfaţa CURS 


J 

/* Urmează definirea atributelor — «/ 
atribute integer cod curs; 

atribute string Denumire curs; 
atribute integer Nr. credite; 

/* Urmează definirea relaţiilor s 


relationship SECȚIE se_predă la 
inverse SECTIE:: are; 

relationship STUDENT frecventat, de 
inverse STUDENT :: frecventează; 

/* Urmează definirea operaţiilor. «/ 

Void şterge_curs () raises (nu există acest curs): 


) 
Interface LABORATOR // Defineşte interfața LABORATOR 


t 
/* Urmează definirea atributelor — «/ 
atribute string Denumire_Laborator; 
atribute string Şef Laborator; 
/* Urmează definirea relaţiilor v 
relationship FACULTATE folosit de 
inverse FACULTATE: foloseşte; 
relationship UNIVERSITATE aparține_de 
inverse UNIVERSITATE :: dispune, de; 
Interface PROFESOR // Defineste interfaţa profesor 
fextent PROFESORI; 
KEYS CNP) 


/* Urmează definirea atributelor v 

atribute integer CNP; 

atribute string NUME-PRENUME; 

atribute integer MARCA: 

atribute string SPECIALIZAREA; 

atribute enum grad-didactic ( prof, conf, lector, asist); 

atribute integer salariu; 

/* Urmează definirea relaţiilor LA 

relationship UNIVERSITATE este. la. 
inverse UNIVERSITATE:: are; 

relationship CATEDRA apar[ine, de 
inverse CATEDRA:: dispune _de; 

/* Urmează definirea operațiilor «/ 

Void majorare_salariu (in float); 


) IM dM C M T 


În cele ce urmează vom căuta să facem câteva precizări pe marginea exemplului de 


utilizare a Limbajului de Definire a Obiectelor, astfel: 


- Cuvântul cheie "interface" este utilizat pentru a defini o clasă şi a asigura 
compatibilitatea cu OMG — IDL. Pentru fiecare interfaţă se poate declara un 
"extent" şi specifică anumite Keys. Extent-ul precizează denumirea pentru setul 
curent de obiecte a acelei clase. E] est analog cu instanța unei relaţii si interfața 
este analogă schemei relației. Dacă utilizatorul nu anticipează nevoia sa lucreze 
cu seturi de obiecte ale unei clase date, deci că ar fi suficient să manipuleze 
individual obiectele, atunci declararea "Extent-ului” poate fi omisă. Distincția 
dintre numele interfeţei (si numele extent-ului într-un limbaj de definire a datelor 
este mai degrabă folosit din punctul de vedere al unui SGBD relafional. Deci, 


where, operatorul de sortare (sort), operatorii unari pentru mulțimi (min, max, count, 


avg) şi operatorul de grupare (group). - 
Formatul clauzei SELECT este foarte apropiat de cel din limbajul standard SQL, si 


întărim precizarea că numele interfeţei ar fi similar cu a da un nume schemei unei 
relaţii (folosind comanda CREATE TABLE nume) şi un nume diferit instanţei 
relaţiei actuale peste acea schemă. Oricum, se apreciază că din punctele de vedere 
practic şi conceptual, valoarea clauzei extent rămâne o problemă de discutat. 


- Clauza Key specifică faptul că extent-ul are o cheie cu o anumită denumire, SELECT [DISTINCT] <expresie> 
Exemplu, extent STUDENT are definită şi o cheie cu denumirea CNP care nu FROM <din-listă> 
permite existența a două instanţe cu o aceiaşi cheie în cadrul extent-ului. [WHERE <extensie>] 

- Proprietăţile claselor de obiecte sunt specificate utilizând ODL şi sunt de trei [GROUP BY <atribule>] 
feluri: atributele, relaţii şi metode. [HAVING «predicat»] 

- Atributele sunt definite ca fiind de tip integer, string, date, enum (pentru liste de [ORDER BY <expresie>] 


valori) ete. 

- Relațiile dintre clasele de obiecte sunt specificate prin clauzele "Relationships" şi 
corespondenja acesteia "inverse relationships"; deci observăm că avem de a face 
cu o definire bidirecţională. 

- La nivelul fiecărei interfețe a fost precizată cu scop exemplificativ câte o 
"semnătură de metodă”, în cadrul cărora apar specificate şi situaţiile de excepție 
folosind clauza "raises". 

În cadrul descrierii structurii BDOO se mai pot desprinde şi alte aspecte evidenţiate 

prin comentarii. 


unde, într-o formă succesivă, elementele din clauza SELECT sunt definite astfel: 
din-listă>:: = <denumire_variabilă> IN <expresie>| 
<denumire_variabilă> IN <expresie>, <din-listă>| 
«expresie] AS <denumire_variabilă>, <din-listă> 


În cele ce urmează vom căuta să oferim câteva exemplificări pentru a observa modul 
de utilizare a limbajului OQL; referirile făcându-se la structura bazei de date orientate obiect 


din figura 7.3. 


Exemplul 1, evidenţiază faptul că nu întotdeauna este necesară utilizarea clauzei 
SELECT FROM WHERE; Este suficient a specifica doar: 


STUDENT 
Aceasta este o cerere completă şi are ca efect obținerea / listarea tuturor studenţilor (ca 


obiecte cu identitate). 


7.7.4. Limbajul de cereri obiect OQL 


Limbajul de cereri obiect (Object Query Language) constituie o extensie a SQL, 
chiar dacă asemănările dintre cele două limbaje sunt mai mult aparente decât reale, în mare 
măsură depind de utilizarea aceloraşi cuvinte-cheie. 

OQL ca si SQL, este un limbaj pur pentru cereri. El nu include, de exemplu, 
controlul structurilor. Din OQL este posibil să se invoce metode care sporesc puterea 
expresivă a acestora. În mod curent OQL nu include primitive pentru actualizarea stării 
obiectelor conţinute în baza de date, aceste actualizări urmând a se realiza cu ajutorul 
metodelor . 

De remarcat faptul că limbajul OQL iniţial a fost elaborat pentru 02, apoi a fost 
adaptat de către ODMG, printr-o serie de modificări, astfel încât actualmente este considerat 
ca un limbaj de cereri standard pentru SGBDOO. EI poate fi utilizat atât ca un limbaj 
autonom, cât şi ca un limbaj înglobat în alt limbaj, pentru care este definită o legătură de tip 
ODMG. Limbajele acceptate în mod curent de către OQL sunt Smalltalk, C++ si Java 
Totodată este de precizat faptul că limbajul OQL poate invoca operaţii programate în 
limbajele amintite anterior. 

O cerere/interogare OQL este o funcție care furnizează un obiect, al cărui tip poate fi 
dedus din operatorul care contribuie la expresia de interogare. $i de această dată facem 
precizarea că rezultatul unei cereri OQL nu este obligatoriu să fie un obiect sau o tabelă. 
aceasta poate fi chiar un întreg, o listă de referinţă a obiectelor, o structură, un ansamblu de 
numere reale sau întreaga structură de date definind un obiect. 

O interogare poate fi compusă dintr-o mulțime, posibil vidă, de expresii, cum ar fi: 
expresii de obiecte, de tip atomic, elementare, de definire a interogării (de forma: 

DEFINE Q AS e; : 
defineşte o interogare cu denumirea Q, pentru o expresie de interogare e dată), de muhimi 
diverse, de conversi etc. A 

Expresiile pot fi compuse în diferite forme, cum ar fi: prin utilizarea cuantificatorulii 
universal (for all), cuantificarea existenţială (exists), testul de apartenenţă (in), clauza select 


Exemplul 2, evidenţiază modul în care este utilizată clauza DISTINCT din fraza 
SELECT: 

SELECT DISTINCT X.Adresa 

FROM X IN STUDENT 

WHERE X Nume = "IONESCU" 


are ca efect retumarea setului adreselor tuturor studenților ce au numele de IONESCU. Mai 
exact, datorită clauzei DISTINCT, se va returna o valoare de tip SET <ADRESE> în care 
valoarea unei adrese apare o singură dată. Cu alte cuvinte, vor fi listate toate adresele la care 
se află studenti cu numele IONESCU, fiecare adresă fiind luată o singură dată. În modelul 
relational, mai precis în algebra relaţională, clauza DSTINCT are semnificaţia de operator de 
proiecţie a relaţiei STUDENȚI pe atributul Adresa. 

Dacă, în cererea de mai sus, ar fi omisă clauza DISTINCT din fraza SELECT, 
cererea ar returna o valoare de tip Bag <ADRESE>; un Bag de adrese este similar cu un 
SET însă poate avea elemente duplicate. 

Tipul SET vine cu metodele încorporate înăuntru, care dă programatorului accesul la 
elementele setului pentru a obține funcționalitatea asigurată de cursori în SQL 
(identificator/pointer, cu ajutorul căruia se manipulează o zonă de memorie alocată si 
gestionată de sistem pentru a se executa o comandă). 


. Exemplul 3 evidenţiază modul de invocare a unei metode în faza SELECT: 
SELECT T. adaugă un nou nr tel ('031_456789) 
FROM T IN UNIVERSITATE 
WHERE T. Denumire = ASE! 
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Are ca efect adăugarea unui nou număr de telefon în setul de numere. Cererea 
actualizează baza de date însă nu returnează nimic apelantului metodei. 


Exemplu 4 are ca scop evidenţierea unei expresii de definire a unei interogări. si 


cere să se găsească toţi studenţii ce au domiciliul stabil în București: E 
DEFINE Bucuregteni AS 2 
SELECT x 2 

FROM x IN STUDENȚI 


WHERE XAdresa = "Bucuregti* 
SELECT X. Nume_Prenume.nume FROM X IN Bucureşteni. 


Exemplul 5 are ca scop evidențierea modului de creare/cunoaștere a unui obiect. 
Precizăm fapti că OQL acceptă două tipuri de obiecte în concepția modelului ODMG: cu 
identitate sau mutabile, având un OID şi fără identitate sau literali, fără OID, în funcţie de 
care diferă si modul de creare sau selecţie. 

În cele ce urmează vom exemplifica modul de creare a unui obiect cu identitate: 


PROFESOR (CNP: 1012644400237, NUME-PRENUME: "BARBU DAN", 
MARCA: 12233, SPECIALITATE: "INFORMATICĂ", 
GRAD-DIDACTIC: "PROFESOR", SALARIU: 3500) 


În situaţia în care anumite proprietăţi/atribute nu sunt inifializate, ele vor lua valori - i 
implicite. £ 
Un obiect cu identitate mai poate fi creat/construit și in alte variante, dintre care una 
ar poate fi aceea care presupune un tip obiect predefinit, care apoi se va inijializa cu valori 
preluate prin selecție dintr-un alt tip de obiecte. Astfel, presupunem că ar prezenta interes de 
stea păstra separat un tip/clasă de obiecte referitoare la toate cadrele didactice având _ 
lizarea “informatică” si descrise prin proprietăţile: CNP, NUME-PRENUME și, 
RAD DIDACUD. Într-o attal de d tipul de obiecte cu denumirea sugestivă de — 
INFORMATICIAN ar putea fi iniţializat/ populat cu valori preluate din tipul PROFESOR, der 
forma: 
INFORMATICIAN (SELECT STRUCT (CNP: X.CNP, NUME_PRENUME: 1 
XNUME. PRENUME, GRAD DIDACTIC: i 
XGRAD DIDACTIC) * 
FROM X IN PROFESOR 
WHERE + X SPECIALIZAREA = 


binisor E 


"INFORMATICA") 


create cu ajutorul tipurilor literale structurate, de forma: 


STRUCT (a : 7, b : 10, c : "BAZE DE DATE") 
Deci, se creează o structură cu trei câmpuri a, b si c. 


7.8. Sisteme de gestiune a bazelor de date orientate 
obiect (SGBDOO) 


În domeniul bazelor date orientate obiect pe piaţa mondială au apărut o serie de 
Sisteme de gestiune a bazelor de date orientate obiect. Unele dintre ele au rezistat timpului şi 
i i a pe ot dn e iama ae, peste la o prezentare a unora dintre 
SGBI 


7.8.1. GEMSTOME 


GEMSTOME este unul dintre primele si probabil cel mai pur sistem de gestiune a 
bazelor de date orientate obiect care a existat ca produs comercial. Este construit pe o 
extensie a lui Smalltalk numită OPAL. 

Spre deosibire de ObjectStore, Ontos şi Versant, care sunt strâns legate de C++, 
OPAL nu este strâns legat de un limbaj anume deşi, limbajul GemStone poate fi accesat şi 
din alte limbaje cum ar fi Smaltalk şi C+. 

GemStone este orientat în principal pe aplicaţii CAD/CAM şi nu tratează moştenirea 
multiplă. 


1.8.2. ONTOS 


ONTOS a fost realizat și comercializat in 1990 de către Ontos Billerica, 

Massachusetts. Utilizează C++ ca limbaj de programare pentru baza de date orientată obiect. 
Ontos este succesorul unui produs mai vechi numit VBase care utiliza un model orientat 
obiect cu propriile sale limbaje COP(C Object Processor — o extensie orientată obiect a 
limbajului C pentru acces la baza de date) şi TDL (Type Definition Language). Ulterior, în 
Versiunea 2.0 TDL este înlocuit cu o extensie orientată obiect a SQL, numită Object SQL 
sau ONTOS SQL, care adaugă sintaxa cererilor obiect la SQL standard. Limbajul COP este 
inlocuit şi el cu C++. 
, Desi este strâns legat de C++, Ontos este accesibil si din alte limbaje. Versiunea 2.0 a 
introdus un 4GL numit Shorthand, un front-end windows, un raport si generator de forme 
numit Studio. De asemenea, are un browser grafic si un instrument (tool) grafic capabil să 
genereze in C++ fişiere şi schema bazei de date. Metodele nu sunt stocate în baza de date așa 
cà trebuie menținute legături între metode şi date. Schema este stocată în baza de date şi este 
accesibilă programatorilor. Clasele speciale sunt prevăzute să modeleze structurile de 
compunere. 

Este suportat in LAN-uri utilizând un model de arhitectură Client/Server. 
Performanța produsului este accentuată de posibilitatea clasterizării (cluster) discului gi 
uilizării tehnicilor Caching. Începând cu Versiunea 2.2 (1993) oferă suport extins pentru 
aplicaii de grup de lucru precum si o mai bună notificare a evenimentelor. 


5 Ping în cape ne edet v RR 
atribute inverse, deci valorile sunt atribute care reprezintă o asociere (valori unice 
sau multiple); 


- tratează obiecte mari de tip BLOB-uri. Pentru ținerea în pagină, atributele foarte 
voluminoase sunt stocate cu ajutorul unei reprezentări în arbori B; 

- gestionează versiuni ale obiectelor; 

- dispune de utilitare pentru administrare, cum ar fi: un browser interactiv pentru 
examinarea şi modificarea schemei bazei de date, comenzi de modificare si 
regrupare fizică a datelor şi un utilitar, numit Make, pentru sincronizarea 
programelor cu o schemă modificată. 


7.8.3. VERSANT 


VERSANT este un alt SGBD orientat obiect realizat de Versant Object Technology 
la Menlo Park în California. Este implementat pe platforma de sistem UNIX, utilizând C++ 
ca limbaj de acces primar însă este posibil şi accesul din Smalltalk sau din Object SQL. 

VERSANT este cunoscut si folosit in mod deosebit pentru aplicaţii multi-user în 
mediu de baze de date distribuite. Este bazat pe o arhitectură multi-client/multi-server. 
Totodată, oferă posibilități de comunicare cu alte sisteme, cum ar fi ORACLE, cu 
instrumente de dezvoltare pentru GUI (Grafic User Interface) sau generatoare de rapoarte. El 
poate asigura si un Depozit de date (Repository) pentru un mediu CASE cum ar fi Rational 
ROSE CASE. Alte caracteristici ale sistemului VERSANT constau în faptul că tratează 
structurile compuse, moştenirea multiplă si variantele de versiuni. 


7.8.4. ORION 


ORION este un sistem orientat obiect realizat de MCC din Austin, Texas. El oferă 
posibilitatea identificării obiectelor, tratarea moştenirii multiple, obiectelor compuse, 
gestiunii versiunilor, indecsilor pentru acces şi tranzacţii. De asemenea oferă suport pentru 
baze de date distribuite, gestionează evoluția dinamică a bazei de date și accesul autorizat la 
date, Este implementat în limbajul LISP, versiunea extinsă orientată obiect a acestuia. 

O particularitate mai deosebită a proiectului de cercetare ORION de'la MCC constă 
în faptul cá se concentrează pe evoluția schemei bazei de date. Schema unei baze de date 
orientate obiect e dinamică şi poate evolua în diferite feluri fără a necesita o recompilare, 
astfel ca permite [34]: 

- Schimbări in descrierea unui obiect prin adăugare, ştergere, actualizare de 

atribute sau metode; 

- Schimbări faţă de reprezentarea obiectelor de către sistem, de genul: adăugare, 

> ştergere sau schimbare de identitate a unui obiect. Ștergerea unei clase de obicei 

are mai degrabă efect asupra tuturor subclaselor sale care moștenesc proprietăţile 

şi comportamentul superclasclor; y 

-= Schimbări în structurile bazei de date ca: adăugare, ştergere sau modificare a unei 
mosteniri, compuneri sau relație asociativă. A 

În general, evoluția sau dezvoltarea structurii baze de date e complicată datorită 
prezenţei moştenirii, în sensul că dacă o superclasă comportă schimbări atunci trebuie 
verificate toate implicaţiile dependente de acea schimbare. Este important de observat că 
identitatea obiectului e păstrată şi trebuie să fie păstrată pe parcursul tuturor schimbărilor 
schemei bazei de date orientate obiect. Pentru acest motiv se presupune că schimbările 
schemei trebuie să fie rezonabile și nu în totalitate. Această problemă este strâns legată de 
cea a controlului de vezsiune si majoritatea bazelor de date orientate obiect oferă un mod de 
control de versiune la nivel de instanță, clasă si schemă. În acest scop, se poate defini o clasă 
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a semnificaţie de istoric care ar conţine ca atribute: versiunea precedentă, versiunea 
“următoare şi membru de set de versiune, care pot fi moştenite de orice obiect care necesită 
“ control de versiune. 

- . Desi ORION a fost in mare parte inspirat după modelul SMALLTALK există un 
“ număr important de extensii în model. De exemplu, moştenirea multiplă e suportată şi există 
trei metode prevăzute pentru rezoluția de conflict. Se folosește fie o regulă „left first” (întâi 
“stânga) prin care este folosită prima superclasă dintr-o listă de superclase de la care se 
moşteneste metoda sau atributul conflictual; sau utilizatorul poate specifica alegerea pe care 
ar trebui să o facă obiectul; sau utilizatorul poate specifica că obiectul trebuie să moștenească 
ambele proprietăţi şi să redefinească una dintre ele. 


785. ITASCA 


ITASCA este realizat si comercializat de ltasca Systems Inc din Minesota, 
Minneapolis. Este un produs software bazat pe prototipurile de cercetare ORION, însă mult 
dezvoltat şi perfecţionat . 

ITASCA ca si ORION utilizează limbajul LISP însă acceptă și alte limbaje de 

gramare cum ar fi: CLOS, C, C++ si Fortran, Rulează pe staţii de lucru UNIX. 

ITASCA se bazează pe o arhitectură multi-client/multi-server distribuită şi oferă 
posibilitatea urmăririi evoluţiei schemei dinamice si a unor servicii bune de securitate si 
concurenţă. Tratează structurile compuse iar notificarea evenimentului poate fi bazată pe 
marcare (flag-based) sau mesaj (message-based). 

ITASCA oferă facilităţile de partiţionare a bazei de date si distribuirea acestor partiti 
în spaţiu geografic, fără a fi nevoie ca utilizatorul să stie unde anume sunt stocate/localizate 
datele. Se foloseşte indexarea claselor pentru a spori performanța, iar unde e posibil cererile 
36 execută în paralel pe diferite maşini din cadrul reţelei. 


7.8.6. 02 


Sistemul de gestiune a bazelor de date orientate obiect O2 a fost realizat in Franța de 
Consorţiul de cercetare Altair între 1986 şi 1990. După 1991 el a fost dezvoltat şi 
comercializat de O2 Technology la Versailles. O2 este implementat în C++ însă anumite 
părți sunt implementate într-un limbaj propriu numit O2C. Este disponibil pe platformele 
UNIX SUN , HP, IBM, BULL şi DEC. 

02 constituie un motor de baze de date, O2 Engine, în interiorul căruia sunt 
disponibile trei niveluri de utilizare: 

- Limbajele de interfaţă: C si C++, un L4G, O2C, limbajul de cereri obiect O2SQL 

şi o interfaţă de programare a aplicaţiilor de nivel de bază O2APL: 

- Utilitare GUI: un generator a interfeţei O2LOOK si un dispozitiv de manipulare 

~ de grafice O2Graph ; 

- Utilitare de mediu: un mediu de programare grafică O2Tools şi un ansamblu de 

componenti O2Kit. 


O2Engine completează toate funcțiunile unui motor de baze de date: răspunde 
cerințelor de lucru într-un sistem distribuit, arhitectura sa răspunde cerințelor unui model 
client-server, distinge gestiunea logică şi gestiunea fizică a datelor, furnizând mecanismele 

de acces concurent si de reprize, de indexare, de optimizare a cerinţelor, de plasament și de 
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prelucrare a datelor. 
În esenţă, O2Engine este compus si privit la trei niveluri: 


răspunde de asigurarea identității obiectelor şi de transmiterea mesajelor lor. EI. 
asigură modelul de persistenţă prin ataşarea şi implementarea strategiilor de — 
indexare şi de regrupare, ecua pe Web o copie I r 
- Managerul hardisc (Disk Manager), componenta O2Store fişiere 1 
tr ăn uitis, M fm Ue dl de dj tore I Toate | 
aceste structuri sunt pliate în pagini, unitatea persistentă de bază. £ 
'O2Store asigură controlul localizării fizice a paginilor pe disc. Totodată, O2 ipaa 
încapsularea la trei niveluri: clase, scheme şi baze de date. K 


7.8.7. Object Store 


Object Store este conceput la Burlington, Massachusetts, fiind orientat pe limbajul de 
programare a bazelor de date C++. Este primul sistem de gestiune a bazelor de date orientate 
obiect ce rulează mai degrabă în mediul MS Windows decât în mediul UNIX. 

Object Store se bazează pc o arhitectură multi-client/multi server pentru a suporta - 
sistemul de lucru distribuit. Bibliotecile de clase sunt prevăzute să suporte versiunile de clase, 
de obiecte, managementul configurării si structurile compuse. Totodată, bibliotecile de clase .— 
suportă indexarea, clusterizarea, cererile asociative managementul relaţiilor si iterarea peste 
seturi. 

În activitatea de programare, pentru adresare se utilizează unele tehnici de pointeri... 
swizzling. Conform unei astfel de tehnici, referinţele de obiecte globale sunt convertite în - 
adrese de memorie locală în momentul în care s-a încărcat un obiect în memoria principală şi — 
invers. [10,67,81]. O astfel de tehnică oferă reducerea timpului de regăsire a datelor, 
solicitate de aplicaţii. 


iati 


4 
E 
7.8.8. OBJECTIVITY/DB 1 
să 
Objectivity (Objectivity Data System Overview; Objectivity, Inc., Menlo Park, | 
California, 1990) utilizează un limbaj de programare de baze de date orientate obiect bazat 2 
pe C++. Este analog cu Object Store, ONTOS şi cu VERSANT. Aditecturs w este de tip ÎI 
client/server distribuită cu un server central, toate operaţiile efectuându-se de o manieră - 
ipoteci tesi, fete do dela, leer uii d eee, eee B 
i exploatare şi reţele heterogene. Limbajul de interfaţă cuprinde o — 
bibliotecă de clase în C++, ^ bibliotecă de funcji C şi SQL*« suportând SQL ANSI 
complet şi numeroase extensii obiect ale lui SQL3. 
Un limbaj de nivel înalt, Object Definition Language (ODL), permite declararea 
conceptelor de modelare precum şi a asocierilor bidirecfionale (relaţii bazate pe atribute. 
inverse). Tratează comportamentul asocierilor între obiecte atunci când avem de a face cu 
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mai multe sesiuni si programarea metodelor de traversare a asocierilor. Toate acestea au ca 
rezultat generarea automată de metode şi de declaraţii C++ şi C. 

Punctul forte a lui Objectivity/DB este arhitectura sa client/Server distribuită, care 
oferă o imagine logică unicat pe multiple baze de date instalate pe maşini eterogene. 
Utilizatorul va avea o imagine logică a obiectelor conectate şi el nu va fi preocupat de faptul 
că un obiect este într-o bază de date pe o staţie de lucru SUN sau că un altul se găseşte într-o 
bază de date sub Windows sau VMS. Toate operaţiile se desfăşoară la modul transparent în 
acest mediu, unde tranzacțiile atomice implică şi validarea în două faze a metodelor de 
propagare şi versionare a stării sistemului. În acest mod se acceptă sub control deplasarea 
obiectelor dintr-o bază în alta şi de pe o platformă pe alta fără afectarea aplicaţiilor în curs de 
desfăşurare şi nici nu reclamă modificarea lor. Schemele multiple sunt create fără afectarea 
altor utilizatori sau baze de date si sunt utilizabile simultan cu schemele partajate, permiţând 
grupurilor locale să-şi definească propriile lor modele. 

Bazele de date sunt detaşabile de acest mediu partajat (baze de date federale) pentru a 
fi utilizate pe periferice portabile, reconectări sau deplasate către un mediu (compatibil) 
diferit sau încă distribuite ca părţi separate sau biblioteci de imagini. 

Objectivity/DB este comercializat de Digital Corporation sub numele de DEC 
ObjecUDB şi este suportat de platformele SUN, DEC, HP/900, IBM, RS/6000, NCR 3300, 
SGI, Windows 3.1., Windows 95, Windows NT etc. 


79. Reguli de evaluare a unui SGBDOO 


Aşa după cum Codd E.F. [17,18] a definit o serie de reguli pentru ca un SGBD să fie 
cu adevărat relafional, tot la fel un grup de lucru de mare influență a publicat, sub denumirea 
de "Manifestul sistemelor de baze de date orientate pe obiecte”, o serie de cerințe sau 
principii pe care trebuie să le îndeplinească un SGBD pentru a putea fi considerat obiectual 
[18]. În concordanță cu Manifestul sistemelor de baze de date orientate pe obiecte, sunt 
definite 13 principii ale SGBDOO, dintre care unele sunt obligatorii iar altele opționale. 

Posibilitatea definirii structurilor complexe. O astfel de cerinţă presupune capacitatea 
de a defini structuri complexe plecând de la tipuri de date atomice folosind o serie de tipuri 
de constructori, iar aceștia să fie ortogonali, în sensul că fiecare constructor trebuie să se 
aplice oricărui obiect. Exemplu, dacă folosim constructori de forma SET (TUPLE( )), LIST 
(TUPLE ( )) atunci trebuie să avem posibilitatea de a folosi şi formele TUPLE (SET ( )) şi 
TUPLE (LIST ()). Dintre cei mai folosiţi constructori amintim: 

- ROW (n.,.....^,.1,), unde un tip reprezintă un rând sau tuplu cu câmpurile 

Ps... de tipurile fs. 

- ARRAY: Tipurile array suportă o metodă "array index" pentru a permite 
utilizatorilor să acceseze articolele array (colecţiei); 

- seturi şi multiseturi (Sets and multisets) . Obiectele set pot fi comparate utilizând 
setul de metode tradiţional <, <, =, >, >. Totodată, două obiecte set (având 
elementele de acelaşi tip) pot fi combinate pentru a forma un nou obiect folosind 
operatorii U,f) si — (diferenţă). 

-~ Liste: Operaţiile pe liste tradiţionale includ capul de listă (head) care returnează 
primul element, coada listei (tail) care returnează adresa ultimului element din 
listă; inserare sau adăugare de noi elemente în listă şi respectiv excluderea unui 
element din listă. 


Mai există o serie de operatori, cum ar fi operatorii agregati (COUNT, SUM, AVG, 
MAX, MIN), şi operatori pentru conversia de tipuri (exemplu, pentru conversia unui obiect 
multiset într-un obiect set prin eliminarea duplicatelor). 

Identitatea obiectului, adică SGBD trebuie să ofere posibilitatea identificării, făra 
ambiguitate, a oricărui obiect din baza de date. În acest sens cu ocazia încărcării oricărui 
pile 0 Neun de dex PRE rit pe Hi n mor ma să e eee pei 

- Încapsularea, presupune faptul că SGBD trebuie să dispună de capacitatea de a 
încapsula datele si metodele aparţinând obiectelor iar utilizatorii pot avea acces la ele doar 
printr-o interfaţă ce citează o anumită metodă. La rândul său atât metodele cât si datele pot fi 
definite publice (+), protejate (#) sau private (-). 

Tipuri şi/sau clase. Cele două concepte trebuie să fie ambele prevăzute. Primul 
concept reprezintă un mecanism de verificare pentru acuratețea programelor în timpul 
compilării. Al doilea concept reprezintă un mecanism care colectează extensiile de obiecte si 
le defineşte implementarea lor. Invers, nu e necesar să fie două forme diferite de a exprima 
tipuri si clase si astfel e posibil să exprimăm un concept în contextul celuilalt. 

Clase şi/sau tipuri de ierarhii, în contextul moştenirii, evidențiază faptul că un 
SGBDOO trebuie să asigure ca un subtip sau subclasá să poată moşteni atributele si 
metodele de la superclasele sau supertipurile lor. 

SGBD trebuie să ofere suport pentru legarea dinamică, în sensul că metodele trebuie 
să se aplice la obiecte de diferite tipuri iar implementarea unei metode va depinde de tipul de 
obiect căruia i se aplică. Acest aspect presupune faptul că sistemul nu poate lega denumirea 
metodelor până în momentul execuţiei (legare dinamică). ; 

SGBD trebuie să ofere un limbaj de manipulare a datelor LMD cu completitudine de 
E În acest sens, de exemplu, se apreciază cà standardul SQL3 posedă completitudine de 
calcul. 

Extensibilitatea mulțimii tipurilor de date, ceca ce presupune capacitatea de a defini 
noi tipuri bazate pe cerinţele utilizatorilor, 

Durabilitatea sau persistența datelor, ceea ce presupune capacitatea sistemului de a 
asigura/suporta persistenta datelor. La fel precum si în situaţia SGBD convenționale, datele 
trebuie să rămână după finalizarea aplicaţiei care le-a creat. Deci utilizatorul nu trebuie să 
deplaseze sau să copieze explicit datele, pentru a le putea refolosi. 

SGBD trebuie să fie capabil şi să ofere facilităţi în ceea ce priveşte operarea si 
gestionarea unor volume mari de date (baze de date de mari dimensiuni). 

Asigurarea accesului concurent la aceleaşi resurse. 

Asigurarea capacităţii de refacere a bazei de date în cazul unor căderi fizice de 
hardware sau software, asemănător sistemelor convenționale. 

Asigurarea unor limbaje de cereri de nivel înalt cu multiple facilităţi de integrare a 
bazei de date. 

Manifestul bazelor de date orientate obiect mai face referiri la câteva caracteristici 
opționale, care sunt interesante şi folositoare dar nu esenţiale pentru un SGBDOO. Dintre 
acestea enumerăm: moştenirea multiplă, distribuţia datelor într-o reţea, posibilitatea 
verificării unui program în timpul compilării, managementul tranzacţiilor şi mecanisme 
pentru managementul versiunii lor. 
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1.10. Limbaj unificat de modelare (UML )-suport 
* 
ntru BDOO 


1101. Ce este UML-ul? 

F Tendinţa actuală din industria software impune dezvoltarea de sisteme extrem de 
complexe si în cel mai scurt timp posibil. Se impune cu necesitate adaptarea procesului de 
dezvoltare a sistemelor informatice la cerinţele din ce în ce mai complexe faţă de produsele 
S În plus, odată cu impunerea pe piaţă a limbajelor orientate obiect si a mediilor 
Vizuale de programare, au apărut în ultimii ani mai multe propuneri de procese de dezvoltare 
orientată obiect a sistemelor informatice, ceca ce a introdus încă o picătură de haos in 


În aceste condiţii, trei dintre cei mai importanți autori din domeniul proiectării de 
software orientat obiect — Ivar Jacobson, Grady Booch şi James Rumbaugh [4]- au conlucrat 
pentru realizarea unui limbaj de modelare standard si a unui proces standard de dezvoltare a 
produselor informatice. Limbajul pus la punct de aceştia - UML (Unified Modeling 

) — înregistrează un mare succes, fiind adoptat ca standard de Object Management 
Group (OMG), organismul de standardizare pentru comunitatea orientată obiect. Deci, UML 
mu reprezinta un standard de metodologie de realizare a sistemelor informatice ci un standard 
de notatii, concepte, simboluri folosite, diagrame utilizate, modele concepute etc. 
Apariția acestui standard reprezintă un mare avantaj dacă ne gândim la multitudinea 
de notații şi metode utilizate până nu de mult în proiectarea orientată obiect şi pe care UML 
le substituie cu succes. În prezent este suficient ca proiectanjii să cunoască acest unic sistem 
de notații. 
UML-ul reprezintă o sinteză a celor mai multe notații și concepte utilizate in 
proiectarea orientată obiect. A început ca o coroborare a activităţii lui Grady Booch, James 
Rumbaugh, si Ivar Jacobson, creatorii a trei dintre cele mai cunoscute metodologii orientate 
obiect, 


În 1996 Object Management Group (OMG) a emis o cerere de ofertă pentru un 
model semantic şi notații standard pentru analiza orientată obicct. Versiunea UML 1.0 a fost 
trimisă ca răspuns la această cerere în ianuarie 1997. Au existat si alte cinci proiecte 
concurente. În cursul anului 1997 toţi cei şase „rivali s-au unit şi au prezentat o versiune 
tevizuită organizației OMG, cunoscută ca UML versiunea 1.l. Acest document a fost 
probat de OMG în noiembrie 1997 sub denumirea OMG UML versiunea 1.1. 

.  UML propune notații standard si semantică corespunzătoare pentru modelarea 
sistemelor orientate obiect. Înainte de aceasta un proiect orientat obiect putea fi descris 
ilizând una dintre zecile de metodologii disponibile, ceca ce făcea ca în cazul unei revizuiri 
cei responsabili de aceasta să piardă mult timp cu analiza notaţiilor şi semanticii 
Metodologiei înainte de a pătrunde logica proiectării. În acest moment, utilizând UML, 
diferiţi proiectanți ce lucrează la diverse sisteme pot înțelege cu uşurinţă munca celuilalt. 


E ——— — (— — 
La această problema au colaborat şi drd. Sandu Daniela si Posdarie Elena 
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7.10.2. Componentele limbajului unificat de modelare 


UML-ul prescrie un set standard de diagrame şi notații pentru analiza şi proiectarea 
orientată obiect a diverselor tipuri de sisteme (sisteme software, sisteme hardware say! 
organizaţii), descriind totodată și semantica acestor diagrame şi simboluri. 

Limbajul unificat de modelare oferă pentru aceasta zece tipuri de diagrame ce pot fi 
grupate astfel: 

- Diagrame pentru modelarea lor de afaceri, respectiv: 

* Diagrama cazurilor de utilizare — în cazul metodologiilor orientate pe cazuri - 
de utilizare, această diagramă dirijează întreg procesul de dezvoltare al 
sistemului * 


- Diagrame pentru modelarea structurii statice, respectiv: 1 
* Diagrama claselor — pentru modelarea structurii statice a claselor sistemului 4 

* Diagrama obiectelor — pentru modelarea structurii statice a obiectelor 
i 


art- 


m 


sistemului 
- Diagrame pentru modelarea dinamicii: 1 
Diagrame de interacțiune, respectiv: * 


= Diagrama de secvență — pentru modelarea circuitului mesajelor între obiecte 

* Diagrama de colaborare — pentru modelarea interacțiunilor între obiecte * 

Diagrame de comportament, respectiv: 1 

* Diagrama de stare — pentru modelarea comportamentului obiectelor a 
sistem D 


* Diagrama de activitate - pentru modelarea comportamentului cazurilor de% 
utilizare, obiectelor sau operaţiilor = 
-  Diagrame de implementare, respectiv: £ 


* Diagrama componentelor — pentru modelarea componentelor 
= Diagrama de desfăşurare — pentru modelarea distribuirii sistemului > 
= Diagrama pachetelor — mijloc de grupare a elementelor diagramelor ini 


În figura 7.28. se prezintă grafic această clasificare a diagramelor UML 
Mecanismele de extensibilitate incluse permit ca in UML să poată fi abordate aspecte care 
nu sunt specificate in standard. Aceste mecanisme permit extinderea notajiilor şi semantici 


pentru clasele şi asocierile utilizate în modelarea proceselor de afaceri. Aceasta prevede, 
stereotipuri ca actor, executant sau entitate pentru o clasă şi stereotipuri de genul i 
simplă sau cale între sursă si destinaţie pentru o asociere. 


200 


Baze de date orientate obiect 


Fig 7.28. Diagramele UML 


Un model grafic nu poate descrie decât o anumită parte din comportament, după care 
alte detalii trebuie specificate în cuvinte. De multe ori însă, utilizarea cuvintelor induce 
ambiguitate. Object Constraint Language (OCL) este standardul UML pentru specificarea 
detaliilor suplimentare sau precizarea constrângerilor modelului. Dezvoltat in cadrul divizici 
de asigurări a IBM ca un limbaj de modelare a proceselor de afaceri, OCL este un limbaj 

nal uşor de utilizat. OCL este mai formal ca un limbaj natural, dar nu la fel de precis ca 
"n limbaj de programare, ceca ce înseamnă că nu poate fi utilizat pentru a descrie logica 
programului sau pentru controlul fluxurilor. Cum acesta este un limbaj destinat expresiilor, 
fazele sale nu au efecte secundare, ele furnizează pur şi simplu o valoare fără a schimba 
starea sistemului. 

O tehnică extrem de utilizată pentru a deslusi funcţionarea modelului orientat obiect 
este analiza orientată pe responsabilităţi cu fişe CRC (CRC cards - Class Responsibility and 
Collaborator cards). Cu ajutorul acestei tehnici clasele identificate în cursul etapei de analiză 
sunt analizate şi selectate pentru a obține doar clasele cu adevărat necesare pentru modelarea 
sistemului, 

. Deși bazele de date orientate obiect devin din ce în ce mai populare, bazele de date 
elaţionale rămân modalitatea curentă de stocare a datelor. Diagrama claselor poate fi 


utilizată pentru a modela baza de date relationalá pe care se bazează sistemul, cu toate astea 
tehnicile tradiționale de proiectare a bazelor de date relationale cuprind mai multă informatie 
şi sunt mult mai nimerite pentru astfel de sarcini. Această lucrare propune modelul entitate 
asociere (Entity Relationship - ER) ca extensie a UML-ului pentru proiectarea bazelor de 
date relafionale. 


7.10.3. Diagrama cazurilor de utilizare 


Cu ajutorul acestei diagrame analistul stabilește aria de a sistemului. 
Simbolurile folosite într-o diagramă a cazurilor de utilizare sunt redate in figura 7.29. 


m 


Fig: 729. Simbolurle diagramei cazurilor de utilizare 


Diagrama cazurilor de utilizare este reprezentarea grafică a cazurilor de utilizare si a 
actorilor (figura 7.30.) şi este adesea însoţită de o descriere textuală. Această diagramă 
documentează interacţiunile sistemului cu mediul, care pot fi interacțiuni cu factorul uman, 
interacțiuni cu alte sisteme şi interacțiuni între calculatoare. 


et 
L Caz ce utilizare 2 
e «comunica» 
em Seutilizeaza> 


Ani Caz de utilizare 1 


Caz de utilizare 3 
Fig. 7.30. Diagrama cazurilor de utilizare (Use Case Diagram) 


Diagrama cazurilor de utilizare furnizează un mecanism de colectare a cerințelor de 
exploatare a sistemului. Ea identifică utilizările solicitate şi comportamentul necesar pentru a 
susţine aceste utilizări şi ajută la identificarea cerinţelor sistemului. Atunci când este utilizată 
în legătură cu diagrama claselor determină limita antrenării unui proiect în soluţii dezvoltate 
concurenjíal, de la sumar la descrieri detaliate, care sunt apoi transformate in scenarii de 
cazuri de utilizare multiple. 

Un scenariu de caz de utilizare este o instanţă a unui caz de utilizare, aşa cum un 
obiect este instanţă a unei clase. O diagramă a unui caz de utilizare nu reprezintă un scenariu 
de caz de utilizare cu un element model, adică o reprezentare grafică. Un scenariu de caz de 
utilizare este alcătuit din informaţii text care detaliază evenimentele şi răspunsurile la acele 
evenimente pentru a satisface cazul de utilizare. Fiecare scenariu de caz de utilizare 
furnizează o legătură vitală pentru înțelegerea soluţiei de afaceri si a soluțiilor tehnice 
posibile care o susţin. 

Fiecare diagramă a cazurilor de utilizare are cel puţin un caz şi un actor. Un caz de 
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utilizare reprezintă secvența acţiunilor pe care sistemul le realizează pentru a produce ceva 
de valoare pentru actorul care interacționează cu sistemul. Cu alte cuvinte, un caz de utilizare 
poate fi privit ca un serviciu, o utilitate sau funcţionalitate oferita de un sistem, subsistem sau 
de o componenta a acestuia unui utilizator oarecare, Intr-o astfel de situaţie, multitudinea 
serviciilor sau funcjiunilor oferite de sistem utilizatorilor definesc funcţionalitatea acelui 
sistem. Actorul / utilizatorul poate fi o persoană sau un alt sistem extern. Un actor poate 
“hp alea călca aa ocu la acelaşi caz de utilizare pot participa mai mulţi 


Entitatea ofertantă de servicii privita ca sistem, subsistem sau o componentă a 
- acestuia pentru utilizatori apare ca o cutie neagră, în sensul că mu este nevoie ca ei să 
cunoască ce confine sau cum este organizată acea entitate. Utilizatorii trebuie să cunoască 
| doar ce servicii îi poate oferi acea entitate. Exemplu, utilizatorii finali ai unui sistem 
informatic trebuie să cunoască doar ceea ce le poate oferi sistemul, cum ar fi: elaborarea şi 
editarea balanței de verificare, bilanţul contabil, rulajul intrărilor, rulajul ieşirilor etc. şi nu 
cum sunt organizate datele în cadrul sistemului, metodele de acces folosite etc. Alte exemple 
şi mai simple ar putea fi cele referitoare la serviciile oferite de un Bancomat (eliberare de 
numerar, consultare sold cont, efectuare de plăţi, alimentarea bancomatului cu numerar etc.) 
sau un Automat de vânzare de bilete de călătorie pentru transporturi feroviare, redat în figura 
731. 


T " 


În ambele cazuri utilizatorii nu sunt interesaţi să cunoască organizarea fizică internă a 
celor două aparate ci doar serviciile posibile oferite de ele. 

O diagramă a cazurilor de utilizare poate conţine trei tipuri de asocieri/relaţii si 
anume: 

- asocieri de comunicare (<<communicate>>, <<comunică>>); 

- asocieri de utilizare (<<uses>>, <<utilizează>>) sau in UML incluziune << 

include>>; 
- asocieri de extindere(<<extends>>, <<extinde>>). 


O asociere de comunicare arată care actor participă într-un caz de utilizare, Este tipul 
implicit de asociere astfel încât nu este obligatorie precizarea acestuia prin stereotipul 
<<comunicate>>. 

Asocierea de utilizare arată că un caz de utilizare trebuie să includă comportamentul 
altui caz de utilizare. Cu ajutorul stereotipului <<uses>> se evidenţiază un comportament 
obligatoriu, uneori împărtăşit în comun de mai multe cazuri de utilizare, 

Asocierea de extindere arată că un caz de utilizare poate include opțional, în anumite 
condiţii, un alt caz de utilizare (de extindere) şi arată dependenţa dintre ele. 


203 


Capitolul 7 


z^ 
[s 


CONSULTARE 
CONDIŢII 
DE TARIFARE 


Casier 


Fig. 7.31. Sistem automat de cumpărare bilete 


7.10.4. Diagrama claselor 


Diagrama claselor este cea mai importantă diagramă în cadrul analizei si proiectării ^ 
orientate obiect. Scopul diagramei claselor este de a structura natura statică a claselor în `- 
termeni de atribute, operaţii şi asocieri (figura 7.32). Majoritatea instrumentelor de modelare — 
orientate obiect generează codul sursă numai din diagrama claselor. 

Celelalte diagrame UML furnizează diferite puncte de vedere din care să fie .— 
identificate atributele, operațiile şi asocierile dintre clase. Ele ajută la validarea diagramei 
claselor, putând servi la clarificarea unei probleme specifice pentru o audienţă specifică. 
Celelalte diagrame din UML există, în principal, pentru a alimenta creşterea si modificarea 
diagramei claselor, fiecare cu o intenţie diferită. 

Diagrama claselor confine clase şi ieri între clase. O clasă este un model pentru 
obiecte cu structură, comportament si relaţii similare. Fiecare clasă are un nume, atribute si 
operaţii. În general numele claselor se scriu cu litere mari. 

Tree Antet Gu Dd OMM MET EO 

Vizibilitate (public (+), protejat (H) sau privat (-)) 

- Tip (implementare limbajului tipului de atribut, cum ar fi caracter sau 


intreg) 
- Valoare iniţială (valoare cu care se inițializează obiectul) 
~ Şirul de proprietăți (valori care se aplica atributului, cum ar fi o serie de numere) | 


Fig. 7.32, Diagrama claselor (Class Diagram) 


Proprietățile, operaţiilor definesc comportamentul si pot include: 
Vizibilitate (public, protejat sau privat) 
- Lista parametrilor (elemente transmise operaţiei care includ tipul sáu propriu şi 
valoarea iniţială) 
-~ Tipul de rezultat (implementare specifică limbajului tipului de atribut a valorii 
rezultate dintr-o operaţie) 
Sirul de proprietăți (valori care se aplică argumentului în lista de parametri) 
O clasă reprezintă cel mai important bloc (structură) dintr-un sistem orientat obiect. 
Si totuşi, în UML clasele sunt doar un tip de clasificatori — denumire dată mai multor 
structuri (blocuri) UML. Un clasificator este un mecanism care descrie caracteristicile 
structurale gi funcţionale (comportamentale). Clasificatorii includ clase, interfeţe, tipuri de 
date, semnale(signal), componente, noduri, cazuri de utilizare şi subsisteme. 
O clasă este o descriere a unui set de obiecte care au aceleași atribute, operaţii, relații 
şi semantică. UML mai are şi alţi clasificatori în afară de clase şi anume: 
- Interfața (interface) - o colecţie de operaţii care sunt folosite pentru a specifica un 
serviciu al unei clase sau componente; 
- Tip de date (data type) - un tip cu valori care nu au o anumita identitate, inclusiv 
tipurile de date primare (cum ar fi numeric sau string), ca de altfel şi enumerările; 
- Semnal (signal) - specificafia unui stimul asincron comunicat între instanţe; 
~ Componenta (component) - partea fizică şi substituibilă a unui sistem din 
care face parte si care asigură realizarea unui set de interfeţe; 
- Nod (node) - elementul fizic care există la execuție şi care reprezintă o 
resursă de calcul, de obicei având memorie si procesor; 
- Cazuri de utilizare - descrierea unui set de secvenţe a acţiunilor; 
Subsistem - un grup de elemente care constituie specificatia comportamentală, 
În UML, clasificatori, deci implicit şi clasele, se caracterizeaza prin următoarele 
proprietăţi: vizibilitatea, scopul si multiplicitatea. 
Vizibilitatea unui clasificator este acea caracteristică care specifică dacă acesta poate 
fi folosit sau nu de alţi clasificatori. 
Există trei niveluri de vizibilitate în UML: 
~ public (+) = are acces orice alt clasificator; 
~ protected (8) - are acces orice descendent; 
- private (-) - numai clasificatorul însuși poate folosi această caracteristică. 
Scopul determină dacă elementul apare în fiecare instanţă a clasificatorului sau exista 


o singură instanţă a elementului pentru toate instanţele clasificatorului. 

În UML, după acest scop, se pot specifica doua tipuri de clasificatori: 

- instance — valori distincte ale elementului pentru fiecare instanţă a 

clasificatorului; 

= classifier — o singură valoare pentru toate instanţele. 

În UML se indică faptul că o clasă este abstractă scriindu-i numele italic. O clasă 
concretă (normala) este scrisa cu fonturi normale. O clasă care nu are descendenți (0 clasă 
frunză) este specificată scriind leaf sub numele clasei. O clasă care nu are ascendenți se 
numeşte clasa rădăcină şi se specifică scriind root sub numele clasei. 

Operaţiile au proprietăţi similare (vizibilitatea si scopul). De obicei o operație e 
polimorfă, ceea ce înseamnă că într-o ierarhie de clase poți specifica operații cu iod 
semnătură în puncte diferite din ierarhie. Operafiile din clasele copii supraîncarcă operații! 
din clasele părinte. Operaţiile, deci, pot fi: abstracte (ex.: funcţiile virtuale din Cri). CH) : 
concrete (leaf) — operaţia nu poate fi suprascrisă (ex.: operaţii nonvirtuale din C++). 

Multiplicitatea reprezintă numărul de instanțe al unei clase. Există clase: 

- cu zero instanţe, este o clasă utilitară care conferă doar atribute şi operaţii; 

- cuo singură instanță, singleton class; 

~ cu un număr dat de instanţe; 

~ cu multe instanțe (cazul implicit). 

Atragem atenţia că în acest context multiplicitatea are o altă semnificaţie față de 

aceeaşi proprietate aplicată asocierilor . 

Multiplicitatea se specifică scriind un număr în colţul dreapta al clasei. Ea se toe 

aplica si atributelor scriind în paranteze o expresie după numele atributului. 
In UML sintaxa unui atribut este: 
[vizibilitate] nume [multiplicitate] [:tip] [= valoare iniţială) [(sir-de-proprietàti )] 

Există trei tipuri de proprietăţi definite pentru atribute: 

- changeable, fără restricţii de modificare; 

- addOnly, pentru atribute cu multiplicitate mai mare ca unu — odată creat nu mai 

poate fi şters sau modificat; 

- frozen - valoarea atributului nu poate fi modificată (ex.: constante din C++). 

Sintaxa unei operaţii în UML este; 

[vizibilitate] nume [(lista-parametri)] [:tip-returnat] [(şir-de-proprietăţi]] 

În semnătura unei operaţii se pot specifica unul sau mai mulți parametrii conform 
următoarei sintaxe: 

[direcţie] nume :tip [=valoare implicită] 

Direcţia poate fi: in (parametru de intrare), out (parametru de ieşire), in-out 
(parametru de intrare care poate fi modificat). 

iuis patru proprietăţi care pot fi folosite pentru operaţii: 
isQuery, starea sistemului rămâne neschimbată; 

- sequential, trebuie coordonat apelul operaţiei astfel încât să se execute doar una 
la un moment dat, 

- guarded, semantica şi integritatea obiectului este garantată în prezența mai 
multor fluxuri (operaţii executate în acelaşi timp), este redusă la un apel 
secvențial executându-se câte una pe rând, 

- concurrent se pot apela de mai multe ori din fluxuri concurente. 

Ultimele trei proprietăţi sunt relevante doar în prezenţa obiectelor active, proceselor 

şi fluxurilor de execuţie (threads). 

Clasele template sunt elemente parametrizate (figura. 7.33). Rezultatul instanfierii 
unei clase template este o clasă care poate fi folosită ca orice altă clasă. 
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Fig. 7.33. Notaţii UML pentru clasele template 


Figura 7.33 indică modul de scriere în UML a claselor template. Clasele template se 
5 specifica implicit prin nume sau utilizând bind care arată că sursa instanţiază template-ul 
pe parametrii actuali. 


4 710.5. Diagrama obiectelor 


Diagrama obiectelor modelează instanțele elementelor conţinute in diagramele de 
clase. O diagramă obiectuală reprezintă un set de obiecte şi relaţiile dintre acestea la un 
anumit moment. 

O instanţă este o manifestare concretă a unei abstractizări a cărui set de operaţii poate 
fi aplicat si care are o stare care arată efectele operaţiilor. Instanţa si obiectul sunt sinonime. 
Grafic, o instanţă este reprezentată subliniindu-i numele. 


€ 


Cele mai multe instanțe modelate cu UML sunt instanțe ale claselor Gi se numesc 
obiecte), deşi există si instanţe de componente, noduri, cazuri de utilizare, asocieri. Instanţele 
modelate se plasează în diagrame obiectuale (pentru detalii a se vedea 7.61). ———— 
Operaţiile care se fac asupra unui obiect sunt definite in abstractizarea obiectului. în 
funcție de moştenire operaţiile pot sau nu fi polimorfe. oy 
Un obiect are o stare care reprezintă proprietăţile obiectului (cele statice de obicei) si 
valorile curente (dinamice) ale acestor proprietăţi. Aceste proprietăţi includ atributele 
obiectului şi părțile lui agregate. Deci, starea unui obiect este dinamică. 

Diagramele obiectuale conţin obiecte şi legături. Ca şi celelalte diagrame, poate 
conține note şi restricţii. Mai pot conţine anumite pachete sau subsisteme, fiecare fiind 
folosite pentru a grupa elementele modelului. . 

Aceste diagrame se folosesc pentru modelarea statică a unui sistem, ca diagramele de 
clase, dar din perspectiva unor instanţe reale sau prototip. 


7.10.6. Diagrama de secvenţă 


Scenariile cazurilor de utilizare se dezvoltă în mod natural din diagrama de secvenţă. 
— Diagramele de secvenţă transformă evenimentele identificate în scenariile cazurilor de 
„ utilizare într-o reprezentare grafică a utilizărilor sistemului de către actor (figura 7.34). 
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Diagrama de secvenţă descrie cronologic interacţiunea obiectelor, identificând | 
mesajele schimbate între obiecte ca răspuns la un eveniment, impreună cu secveaa 
mesajelor. Intenţia este de a stabili limitele contextuale ale scenariului cazurilor de utilizare, 
Este prima vizualizare a intercomunicării claselor pentru un anumit scenariu al cazurilor de 
utilizare. Scopul nu este captarea imediată a operaţiilor, ci înțelegerea ordinii evenimentelor 
pentru a parcurge întregul scenariu. Pe măsură ce ordonarea devine stabilă, un eveniment 
devine o operaţie specifică pe care o iniţializează obiectul receptor. ^ 

Diagramele de secvență sunt recomandate pentru realizarea de specificaţii In timp 
real și pentru scenarii complexe. O diagramă de secvență avansată arată, de asemenea, 
execuţia condiţională. E 

Diagrama de secvență listează obiectele diagramelor de secvență implicate întru 
scenariu al cazurilor de utilizare în partea superioară de la stânga câtre dreapta. Când se 
include numele clasei cu numele obiectului, se separă clasa de obiect prin ":". 

Se plasează mesajele schimbate între obiecte, pe verticală de sus în jos. Perioada de 
existenţă se propagă în jos, de la fiecare obiect. Pentru fiecare pas în scenariul cazurilor de 
utilizare, un obiect trimite mesajul din linia sa de viaţa către linia de viaja a unui alt obiect. - 
Mesajul conține informaţii necesare obiectului doi să acţioneze, Cu alte cuvinte, mesajul 
declanşează o acţiune în obiectul receptor. Un obiect poate să fie atât receptor cât şi emițător 
(recursiv). Optional se poate include un actor care să participe în scenariul cazurilor de | 
utilizare ca fiind un obiect care trimite şi primeşte mesajele. Un singur pas în timpul 
scenariului cazurilor de utilizare uneori poate crea sau distruge un obiect. Linia de viaţă a 
obiectului se monitorizează prin alinierea verticală a obiectului cu pasul său de instanţiere. 
Se marchează cu X sfârşitul liniei de viaţă, adică pasul în care obiectul este distrus. 

Dreptunghiul de-a lungul liniei de viață a obiectului arată durata acţiunii, numită 
activare sau amplificarea controlului, începând cu mesajul primit şi terminând cu mesajul 


trimis. 
Forma diferită a săgeţilor reprezintă tipuri diferite ale mesajelor. Mesajul sincron, - 
unde obiectul care l-a trimis așteaptă răspunsul de la obiectul care l-a recepționat, este ^ 
E: 4 


— 


Săgeata mesajului de răspuns are aceeași formă. Când obiectul care trimite mesajul 
nu aşteaptă răspunsul, cazul mesajului asincron, săgeata are următoarea forma: bi 
d mma lb. 


Baze de date orientatc obiect 


j DIAGRAMA DE SECVENTA 
[M 


Fig. 7.34. Diagrama de secvenţă (Sequence Diagram) 


Se spune că procedura are vârful de săgeată substituit. Mesajul de răspuns nu are nici 
un vârf pe săgeată şi în schimb are liniufa verticală plasată în apropierea mesajului original 
timis. Daca paşii se repetă, mesajele se plasează în interiorul unui dreptunghi. Se poate 
adăuga textul iterafiei pentru indicarea numărului de iterații si a condiţiei de ieșire. Textul 
are forma: ,[i:71..5]" cu semnificaţia: „repetare folosind variabila i, de la 1 până la un număr 


7.10.7. Diagrama de stare 


Modelează starea dinamică a unui obiect specific. Diagrama de stare constă din stări, 
Piper soro e taahi k 7 350. 
i mot ee i i care fac tranziția unui obiect dintr-o stare 
în alta. Conform UML, o stare este „o condiție sau o situaţie din momentul existenţei unui 
obiect care satisface în acel moment anumite condiţii, efectuează anumite activităţi sau 
aşteaptă anumite evenimente”. Diagrama de stare descrie toate operaţiile şi atributele unei 


teprezentată prin acelaşi cerc dar inclus într-un cere puțin mai mare. Starea iniţială apare la 
crearea obiectului. Starea finală apare la dispariţia obiectului. 


— p 


pr indică punctul de start (crearea obiectului) + 


indică punctul de stop (distrugerea obiectului). 


ermrinentiperametu!. parametri) ondüet) / actos! 


Fig. 7.35. Diagrama de stare (Statechart Diagram) 


Diagrama de stare identifică evenimentele care fac tranziţia unui obiect dintr-o stare 
în alta. Conform UML, o stare este „o condiţie sau o situaţie din momentul existenței unui 
obiect care satisface în acel moment anumite condiţii, efectuează anumite activităţi sau 
aşteaptă anumite evenimente”. Diagrama de stare descrie toate operaţiile si atributele unei 
Clase în timpul unui eveniment. Diagrama identifică stimulii care declanșează acțiunea. 
Diagrama include numele stării, oricărei variabile, în timp ce obiectul este în funcţiune, şi 
evenimentul care declanșează tranziţia la o nouă stare. 

Dreptunghiul cu marginile rotunjite reprezintă stări distincte. Orice diagramă de stare 
include o stare iniţială reprezentată printr-un cerc mic de culoare neagră şi o stare finală 
reprezentată prin același cerc dar inclus într-un cerc puţin mai mare. Starea inițială apare la 
crearea obiectului. Starea finală apare la dispariția obiectului. 

Cu excepția stării inițiale şi a celei finale fiecare stare are un nume, atributele proprii 
unei stări, acţiunile şi activităţile efectuate. Acestor acţiuni și activităţi le este atribuit un 
nume de eveniment, precum și argumente si expresii ale acţiunii. Slash-ul "7", separă 
expresiile acţiunii de la numele evenimentului şi argumentele. Acţiuni speciale includ: 

* Entry / intrare - acţiune efectuată la intrare într-o stare 

- Exit/ ieşire - acţiune efectuata la ieşire dintr-o stare 

- - Do / acţiune efectuată aflându-se într-o stare; evenimentele externe pot întrerupe 

acţiunile Do. 

Obiectul tranzitează dintr-o stare în alta când apare un eveniment şi când sunt 
îndeplinite anumite condiţii. Tranzifia este arătată cu liniuţe simple de la o stare existentă 
către o stare de intrare / țintă. Tranziţia conţine: 

- semnătura unui eveniment care include un nume si argumentele separate de 

virgule care se află între paranteze 

- o condiție de securitate opţională care interzice tranziția de stare până când nu 

sunt îndeplinite toate condiţiile 

= o acţiune introdusă cu slash ,/" 

În timpul tranziţiei se execută o acţiune. Acţiunea poate să fie o operație efectuată de 
obiect, un mesaj trimis altui obiect, sau o condiţie în cadrul obiectului care declanșează 
schimbarea stării. Acţiunea însăși poate include o semnătură când acţiunea trimite un mesaj 
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altui obiect. Expresia acţiunii poate include obiectul receptor și parametrii transmişi acelui 
obiect receptor. O săgeată reprezintă trimiterea unui mesaj către un alt obiect. Acest mesaj 
poate fi trimis de la obiect în timp ce este într-o anumită stare sau în timpul tranziţiei. 


7.10.8. Diagrama de colaborare 


Diagrama de colaborare descrie o examinare non-secvențială a modului în care 

interacționează obiectul. Diagrama de colaborare suportă multiple modalităţi de modelare a 
— obiectului. O modalitate arată modul în care obiectele colaborează în cadrul unui singur 
- scenariu al cazurilor de utilizare similar cu diagrama de secvenţă. O interacţiune interesantă 
- se produce între diagramele de secvenţă si diagramele de colaborare, rezultând operaţiuni 
 intensificate si descoperirea unor atribute adiționale. Ambele diagrame furnizează puncte de 
vedere diferite ale aceleiaşi informaţii. Ambele arată implementarea unui scenariu al cazului 
de utilizare. Diagrama de colaborare filtrează timpul sau examinarea secvențială a 
„ scenariului pentru a studia asocierile statice şi comportamentele dinamice ale obiectelor 
implicate în interacţiune. Avem tendința să gândim secvențial, dar câteodată, procesele nu 
sunt atât de procedurale cum ni le imaginăm. Utilizarea diagramei de colaborare poate ajuta 
la clarificarea contextului. 

Diagrama de colaborare poate fi utilizată pentru a arăta legătura tuturor operațiunilor 

unei anumite clase. Pentru fiecare operaţie, este arătat obiectul țintă al operat i 
obiect pe care îl solicită pentru a implementa operaţia. Diagrama de colaborare, astfel, 
devine un context al tuturor obiectelor şi al asocierilor care interacționează cu un obiect 
(figura 7.36). 


DIAGRAMA DE COLABORARE 


Fig. 7.36. Diagrama de colaborare (Collaboration Diagram) 


Deoarece permite focalizarea asupra unei anumite clase, diagrama de colaborare ajută 
la rafinarea di i claselor, adăugând atribute si operaţii. Furnizează, de asemenea, 
informaţii cu privire la ceea ce face o clasă atunci când validează codul asociat acesteia. 

Notaţia UML a diagramei de colaborare este asemănătoare cu diagrama de secvență 
Cu obiecte, mesaje şi semnături, Fiecare mesaj poate include un număr secvențial care să 
ordoneze etapele colaborării. Virgulele separă secvențele şi se termina cu un slash „/”. 
Un predecesor în numărul secvenfei indică faptul că alt mesaj trebuie completat înaintea 
transmiterii acestui mesaj. 

E Diagrama de colaborare poate arăta un comportament repetat cu un asterisc, „*”, 
mat de numărul de iterații şi de condiţia de ieşire încadrată între paranteze, de exemplu, 
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[iz la]. 


7.10.9. Diagrama de activitate 


O diagramă de activitate permite o mai bună înțelegere a operaţiilor, în special a celor — 
foarte complexe. Diagramele de activitate permit mai buna înţelegere a detaliilor din cadrul 
unei operaţii a unei clase. Diagramele de secvenţa si de colaborare nu captează acest nivel de - 
detaliere suficient de exact pentru ca ele arată doar mesajele schimbate între obiecte, nu şi — 
detaliile asociate acestor obiecte. Alte activităţi complexe pot necesita un mai mare. 
rafinament într-o altă diagramă de activitate care să arate stările sub-acţiunilor și sub- + 
tranzifiile. È 

Diagrama de activitate este un tip de grafic de stare care specifică activitatea unei 
anumite clase (figura 7.37). 

Diferența consta în faptul ca un grafic de stare reprezintă întregul obiect, în timp ce o ~ 
diagramă de activitate reprezintă în mod tipic doar o operație în cadrul unui obiect: 
Terminologia diagramei de activitate este uşor confundată eu terminologia diagramei de= 
stare întrucât ambele utilizează termenul „stări”, Starea din cadrul diagramei de activitate 
este stare a unei acţiuni, noţiune distinctă de stare a obiectului. 1E 


DIAGRAMA DE ACTIVITATE 


Fig.7.37. Diagrama de activitate (Activity Diagram) 


Starea acțiunii reprezintă starea unei activități în cadrul unei 


operații. Descric 
descompunerea stării de acțiune şi tranzițiile în cadrul unei anumite stări i 


a obiectului, mai! 


pentru a arata această prelucrare internă. 


Baze de date orientate obiect 


Să luăm, drept exemplu, un automat. Când consumatorul introduce banii într-un 
automat, activitatea de a da consumatorului un produs poate traversa mai multe acţiuni de 
sare. De exemplu, oferirea restului, lăsarea produsului să cadă în tavă, avansarea liniei de 

. Totuşi, nici una dintre aceste stări ale acțiunii nu reprezintă stare a obiectului 
sutomatului (aşteptarea selecţiei, livrarea produsului). 

Starea acţiunii poate fi declanșată de : 

- Completarea unei operaţii, 

- Completarea unei stări, a unei acţiuni anterioare sau 

- Disponibilitatea unui obiect (starea necesară unei acţiuni pentru a începe). 

Activitatea constă în etape procedurale sau operaţii declanşate mai degrabă de 
prelucrarea internă decât de evenimente externe. O stare specifică unui obiect sau 
completarea uneia din operaţiile sale declanșează o operaţie, o acţiune în cadrul unei stări a 
acţiunii este deseori ea însăşi o operație. Când se termină o acţiune, poate face un obiect 
disponibil pentru o acţiune următoare. Când se întâmplă acest lucru, activitatea s-a mutat 
către starea sa de acţiune următoare. 

Un dreptunghi cu colțurile rotunjite înconjoară acţiunea; capetele deschise ale 
săgeţilor indică fluxul controlului. Poate include atributele utilizate de o acţiune, dar poate 
doar să utilizeze atributele şi link-urile obiectului care le deţine (de exemplu, obiectul pentru 
care se defineşte activitatea). 

O diagramă de activitate poate avea ramuri de control comune sau separate, Aceste 
fluxuri de acţiune au drept etichetă condiția care declanşează fluxul. 


7.10.10. Diagrama componentelor 


Diagrama componentelor adună informaţiile din diagrama claselor pentru a crea 
componente. Diagrama componentelor modelează dependența componentei software. în 
funcție de codul sursa, codul binar şi componentele executabile (figura 7.38). 


Fig. 7.38. Diagrama componentelor (Component Diagram) 


Notatia UML pentru componente este dreptunghiul cu două dreptunghiuri mai mici 
scoase în afară, pe una din părți. O componentă are un nume şi opțional un tip separate prin 
ni”. Componenta poate include obiectele pe care le confine. 3 

Un vârf de săgeată deschis de la o componentă la alta indică o dependență a sursei de 
țintă. O relație de dependență reprezentată de un cerc deschis şi o etichetă de interfaţă pot fi 
trasate către interfața obiectului; aceasta este inițierea dependenței. O dependență poate fi de 
asemenea trasată direct către componentă fără trecerea printr-o interfață; aceasta este o 
dependență de compilare. 


7.10.11. Diagrama de desfăşurare 


Componentele sunt "plasate" pe echipamente hardware prin intermediul diagramei de 
desfăşurare. Diagrama de desfăşurare modelează procesoare şi echipamente fizice, 
securitatea si componentele care sunt plasate pe procesoarele fizice (figura 7.39). 

DIAGRAMA DE DESFASURARE 


Fig..39. Diagrama de desfășurare (Deployment Diagram) 


Diagrama de desfăşurare reprezintă partiţionarea componentelor şi a obiectelor active 
(de exemplu, o baza de date) pe locația lor fizică, Acest tip de diagramă detaliază locul de 
amplasare a componentelor în cadrul infrastructurii sistemului. Cel mai adesea sunt definite 
mai multe diagrame de desfășurare independente. 3 

Diagrama de desfășurare utilizează noduri pentru a reprezenta procesoare $i 
echipamente, Fiecare nod are un nume şi, opţional, un tip, separate de două puncte, 

O linie continuă de la un nod la altul indică faptul că nodurile comunică, de exemplu. 
printr-un canal sau o rețea. Un vârf de săgeată deschis indică faptul că o componentă 
comunică cu un obiect activ. 


7.10.12. Diagrama pachetelor 


UML furnizează mijloace de grupare a elementelor din cadrul diagramelor, numite 
pachete. Într-un pachet pot fi ambalate alte pachete, clase, cazuri de utilizare, colaborări ctc- 


214 


Un pachet arată doar structurile pe care le contine (figura 7.40). 

Un pachet nu arată comportamentul elementelor sale. Un element de modelare 
aparține unui singur pachet, dar alte pachete pot consulta acest element. Dacă se arată 
explicit conținutul pachetului, atunci numele pachetului se trece pe etichetă. Un pachet este 

Tun mecanism destinat unor scopuri generale, care organizează elementele în grupuri. Fiecare 
pachet are un nume care poate fi simplu sau cu cale (path name). De exemplu: — nume 
nume cale -senzori :: viziuni 


DIAGRAMA PACHETELOR 


BD Cu 


Fig. 7.40. Diagrama pachet (Package Diagram) 


,, Un pachet poate conţine clase, interfeţe, componente, noduri, colaborări, cazuri de 
utilizare, diagrame şi chiar alte pachete. ,A confine" este o relaţie compusă, ceea ce 

Că fiecare element este declarat în pachet. Din punct de vedere al vizibilităţii 
Pachetele se comportă precum clasele, 

Importul unui pachet - Presupunem ca avem clasa A în pachetul A și clasa B în 
Pichetul B. Fiecare sunt elemente publice ale pachetului său, Daca pachetul A importă 
Pachetul B, A poate vedea B, dar B nu poate vedea A. Importul acordă o permisiune eu un 
Singur sens elementelor unei clase asupra elementelor altei clase. 

„Există două tipuri de relaţii între pachete: importul şi dependentele acces, folosite 
Pentru a importa într-un pachet elementele exportate de altul si generalizările, folosite pentru 
A specifica familii de pachete. Un pachet specializat poate fi folosit oriunde este folosit un 
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7.10.13. Interacțiunea dintre diagramele UML 


Pe parcursul ciclului de viață al unui sistem informatic diagramele UML 
interacționează între ele sau cu alte modele (modelul entitate asociere), figura 7.41. b 
Cazurile de utilizare şi diagramele de interacțiune. Toate procesele care trebuie 
executate de sistem se regăsesc într-un caz de utilizare. Procesele sunt descrise apoi textual — 
sau printr-o succesiune de pagi. Pentru modelarea grafică a scenariilor poate fi utilizată 
diagrama de activitate. Odată ce comportamentul sistemului a fost astfel surprins, cazurile de 
utilizare sunt mai departe analizate pentru a identifica cum interacționează obiectele pentru a 
modela acest comportament. Diagramele de secvenţă si de colaborare sunt utilizate pentru a ~ 
modela această interacţiune între obiecte. : 
Clasele, obiectele şi diagramele de implementare. Pe măsură ce sunt identificate 
obiectele, acestea pot fi grupate si clasificate în cadrul diagramei claselor şi a obiectelor. - 
Diagrama claselor devine astfel elementul central al procesului de proiectare orientat obiect, 
fiind diagrama care descrie structura statică a sistemului. Diagrama claselor poate fi 
împărţită pe trei straturi care să evidenieze clasele ce descriu interfaţa cu utilizatorul 
(business layer), clasele responsabile de logica aplicaţiei (application layer) şi clasele pentru 
stocarea datelor (data layer). Diagrama componentelor este utilizată pentru a grupa clasele în 
componente sau module. Distribuirea fizică în ansamblul sistemului este modelată cu 
ajutorul diagramei de desfăşurare. 
Fişe CRC — o extensie informală a UML-ului. Ca extensie a UML-ului, tehnica 
fiselor CRC poate fi utilizată pentru a supune sistemul analizei orientate pe responsabilităţi. — 
Clasele sunt analizate, seleciate şi rafinate pe baza responsabilitàfilor lor în cadrul sistemului 
şi a claselor cu care acestea trebuie să colaboreze pentru a-și îndeplini aceste responsabilităţi. 
Diagramele de stare. Cu ajutorul diagramelor de stare se modelează comportamentul 
în timp real al fiecărei clase cu un comportament semnificativ dinamic. Diagrama de 
activitate poate fi si ea folosită, de această dată ca extensie a diagramei de stare, pentru a 
detalia acţiunile de răspuns ale obiectelor la evenimente interne acestora. Diagrama de 
activitate poate fi utilizată şi pentru a reprezenta grafic acţiunile metodelor claselor. - 
Implementarea proiectării (realizarea sistemului). Realizarea sistemului presupune .— 
transformarea informaţiei cuprinsă în mai multe modele UML in cod şi structură a bazei de. : 
date. Ín cazul unui sistem de mari dimensiuni este extrem de utilà acestuia in > 
trei subsisteme: subsistemul afacerii, care include şi elementele de interfaţă cu utilizatorul ;. 
(business layer), subsistemul aplicaţiei, care include obiectele de implementare af 
funcţionalităţii sistemului (application layer) şi subsistemul datelor, care include structura, 
bazei de date si obiectele de acces la această structură (data layer). 
implementarea aplicaţiei (codificarea). Diagrama claselor este utilizată pentru D 
genera scheletul aplicaţiei în limbajul de programare ales cu ajutorul unui C. 
Diagramele de interacţiune, de stare şi de activitate furnizează informaţii suplimentare pentru, 
detalierea părții procedurale a codului. 
Proiectarea bazei de date. Stratul datelor (data layer) din diagrama claselor poate fi 
utilizat pentru a proiecta direct o bază de date orientată obiect sau pentru a construi 
corespunzător un model entitate asociere (ER - Entity Relationship) pentru o analiză mai 
detaliată a relaţiilor. Pe baza modelului entitate asociere se poate construi apoi modelul fizic, 
al bazei de date relaționale. 
Testarea cerințelor. Diagrama cazurilor de utilizare este folosită şi pentru a testa dacă, 
sistemul răspunde cerinţelor inițiale. Se parcurg toate cazurile de utilizare pentru a vedea, 
dacă sistemul corespunde cerinţelor clientului 


Baze de date orientate obiect 


7.10.14. Avantajele utilizării UML 


Deşi nu garantează succesul unui proiect informatic, UML poate contribui la 
reducerea costurilor de instruire şi schimbare a instrumentelor de lucru atunci când se face 
trecerea de la un proiect la altul sau de Ia o organizaţie la alta. UML oferă o bază pentru 
integrarea instrumentelor, proceselor şi domeniilor. În primul rând, UML asigură o 
terminologie unică şi permite realizatorilor de sisteme să se concentreze asupra obiectivelor 
proiectelor şi nu asupra instrumentelor de modelare. 

Aşa cum a fost precizat în documentul UML Summary, Version 1.1, elaborat la 1 
septembrie 1997 de Rational Software şi ceilalți realizatori, scopurile pentru care a fost creat 
UML sunt următoarele: 

- så pună la dispoziţia utilizatorilor un limbaj de modelare vizual uşor de folosit, 
expresiv. Este foarte important ca standardul pentru analiză şi proiectare să 
suporte un limbaj de modelare care să fie folosit pentru realizarea de taskuri 
generale de modelare. Dacă standardul oferă numai o descriere de meta-nivel care 
reclamă ajustarea la un anumit set de concepte de modelare, atunci nu se poate 
realiza schimbul de modele fără pierdere de informații; 

- să asigure extensibilitatea precum și mecanismele de specializare prin care să fie 
extinse conceptele de bază; 

- să permită formularea de specificaţii independente de un anumit limbaj de 
programare şi de procesele de realizare a sistemului; 

- să ofere o bază formală pentru înțelegerea limbajului de modelare; 

- să încurajeze creşterea pieţei instrumentelor orientate pe obiecte; 

- să suporte concepte, precum: componente, colaborări, cadre; 

- să permită diseminarea celor mai bune practici în domeniul realizării sistemelor 
software, 

UML reuneşte conceptele din Booch, OMT şi OOSE. Rezultatul îl reprezintă un 

limbaj de modelare posibil de utilizat de către utilizatorii acestor metode, dar şi a altor 
metode orientate pe obiecte. 


Fig. 7.41: Interacțiunea dintre diagramele UML, tehnica fişelor CRC şi modelul entitate asociere 


În plus, UML extinde posibilitățile oferite de metodele menționate mai. sus. De 

lu, prin utilizarea UML se poate realiza modelarea sistemelor concurente şi a celor 
distribuite. 

* UML asigură un standard de limbaj, nu și de proces. Deşi UML poate fi folosit în 

unei metodologii, experiența echipei de proiect şi specificitatea domeniului pot reclama 

„şi o aceeași notație, pentru interpretarea acestei semantici. UML promovează construirea 


unor procese specifice. UML asigură un același meta-model, care unifică semantica 
iertivă şi incremeatală a sistemelor software dirijată de cazurile de utilizare şi centrată pe 


71. Modelarea orientatá obiect 


Un model orientat obiect are la bază obiecte. Un obiect încapsulează atât date cat si 
comportament, ceea ce înseamnă că analistul poate folosi abordarea orientată obicct atât 
pentru modelarea datelor cât şi pentru modelarea proceselor. Pentru că permite analistului de 
sistem să surprindă ambele aspecte într-o singură reprezentare şi pentru că oferă și alte 
beneficii cum ar fi mecanismul moştenirii si reutilizarea codului, modelarea orientată obiect 
oferă un mediu puternic pentru dezvoltarea sistemelor complexe. Teoria obiectelor, 
Încapsularea, moştenirea si polimorfismul stau la baza dezvoltării obiectuale a sistemelor. 

Există o varietate largă de metodologii şi tehnici utilizate de către un analist de sistem 
în procesul de analiză si proiectare orientată obiect. 

Referitor la consistenţa modelelor, în alte abordări — cum ar fi analiza şi proiectarea 
structurată — modelele care se dezvoltă nu folosesc notații comune si sunt slab conectate între 
ele, tranziţia de la un model la altul făcându-se în mod abrupt. Abordarea orientată obiect 
_oferă continuitate în ceea ce priveşte tranziția între modelele analizei, proiectării si ale 
“implementării. De exemplu, trecerea de la analiza orientată obiect la proiectarea orientată 
obiect presupune îmbogățirea modelului de analiză cu detalii referitoare la implementare şi nu 
dezvoltarea unui nou model. 


7.11.1. Modelarea domeniului (mediului) — Domain Model 


Pentru a aprofunda înțelegerea contextului în care va funcţiona sistemul se utilizează 
modelul mediului (domeniului). Acest model cuprinde cele mai importante clase întâlnite în 
domeniul economic pentru care se realizează sistemul informatic şi are un caracter de 
generalitate. Clasele se identifică fic din cerinţele exprimate de beneficiar, fie din 
intervievarea unor experti în domeniu. Este unul dintre primele modele utilizate în analiza 
trientată obiect si are menirea de a sistematiza expertiza din domeniul analizat si a o transmite 
Sistemului informatic ce urmează a fi proiectat. 

Sent trei pori dă Mage Gere poH puse fit evidengiha acest oale 
clase ce modelează obiecte sau concepte utilizate in cadrul sistemului 
informaţional analizat, cum ar fi comandă, contract, factură; 

- obiecte sau concepte din lumea reală pe care sistemul trebuie să le înregistreze si 

5 să ţină cont de ele, cum ar fi cursul de schimb al monedei de referinţă; 

~ evenimente ce intervin şi afectează starea sistemului, cum ar fi plasarea unei 
comenzi, plata unei facturi. 
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Baze de date orientate obiect 


„Pentru descrierea acestui model vom utiliza preponderent diagrama claselor, 
instrumentele puse la dispoziție de UML. Aşa cum am văzut în capitolul anterior di 
claselor reprezintă atât entitățile domeniului (clasele) cát si relațiile dintre acestea ( 
figura 7.42. 
Aşa cu am mai precizat scopul principal al acestui model este înțelegerea 
sistemului. De aceea la realizarea modelului mediului ep 


se folosi o terminologie unitară. Se preferă pentru a se evita obținerea uil 
model prea mare si greu de utilizat. 2 

Uneori, pentru sistemele de mici dimensiuni, se renunță chiar la diagrama clasele 
pentru modelul mediului, întocmindu-se doar acest dicționar de termeni. I 

Dicţionarul este deosebit de important si pentru asigurarea unui limbaj comun fa 
cadrul proiectului. Cu toții intuim problemele ce pot apare în comunicare datorită utili 
unei terminologii necunoscute de toţi cei implicaţi în proiect. 

În final trebuie să atragem atenția că la acest nivel analistul nu trebuie să insiste prea 
mult pe clasele interne sistemului, acest model fiind destinat identificării şi înțelegerii 
cerințelor ce derivă din contextul sistemului. Modul în care sistemul va trata aceste probl 
logica internă, urmează să fie detaliate în alte etape, cu ajutorul altor modele. 

Modelul mediului, format din diagrama claselor domeniului şi dicţionarul de te A 
poate fi utilizat atât la dezvoltarea modelului cazurilor de utilizare cât şi la identificarea 
claselor sistemului în etapa de analiză. 


Fig. 7.42. Diagramă a claselor ce modelează domeniul aplicației 


7.11.2. Modelarea proceselor afacerii (prelucrărilor) — Business 
Model 


; Aceasta este o tehnică de modelare utilizată pentru a aprofunda jelegerea 
specifice unei organizaţii, Deşi denumirea ar putea părea Inge ESTI 


laii termen si pentru sistemele care nu informatizează o „afacere”, cum ar fi un sistem de 
dirmi sau un controler hardware. 

Utilizând UML, modelarea afacerii se poate face din două perspective: fie prin 
modelul cazurilor de utilizare, fie prin modelul obiectelor. 

În cadrul modelării cazurilor de utilizare (business use-case model) se surprinde 
acţionarea sistemului din perspectiva utilizatorilor acestuia. Procesele se modelează prin 
cazuri de utilizare, iar iniţiatorii acestor procese prin actori (figura 7.43). 

Modelul obiectelor (business-object model) surprinde prelucrările din interiorul 
sistemului. Descrie în detaliu cum este tratat fiecare caz de utilizare. Realizarea cazurilor de 
zilizare se poate evidenția cu ajutorul diagramelor de interacțiune (diagrama de secvenţă, 
diagrama de colaborare) sau al diagramei de activitate. 

O entitate a sistemului existent (a afacerii) reprezintă un lucru pe care utilizatorii îl 
xceseazá, consultă, manipulează, realizează sau utilizează în cadrul unui caz de utilizare. O 
unitate de lucru este un set de astfel de entităţi care formează un întreg pentru utilizatorul 
final. Entitàfile şi unităţile de lucru sunt utilizate pentru a reprezenta aceleași concepte ca şi 
clasele din modelul mediului (comandă, produs, factură, cont). 


Administrator 


Fig. 7.43. Modelarea proceselor afacerii cu ajutorul diagramei 
cazurilor de utilizare 


Fiecare utilizator, entitate sau unitate de lucru poate participa la realizarea a mai 
multor cazuri de utilizare. De exemplu in figura 7.43. „Utilizatorul” participă la realizarea a 
touă cazuri de utilizare, la fel şi „Administratorul”. 

Un astfel de model se dezvoltă în doi paşi: 

- Realizarea modelului cazurilor de utilizare 

- Detalierea modelului prin specificarea utilizatorilor, entităţilor şi a unităţilor de 

lucru, dar şi a regulilor care guvernează anumite procese sau obiecte. 

Scopul este crearea unor utilizatori, entităţi şi unităţi de lucru care rezolvă problema 
evidenţiată de cazul de utilizare eficient — bine, rapid şi Ia cel mai scăzut cost posibil. 

Modelarea mediului şi modelarea afacerii par întrucâtva asemănătoare, mai ales dacă 
e gândim că entităţile şi unităţile de lucru corespund claselor din modelul mediului. Există 
totuși o serie de diferente, dintre care evidenfiem trei. 

Cele două abordări diferă în primul rând prin modul de documentare. Una se bazează 
Pe cunoştinţele unui expert în domeniu sau pe cunoştinţele despre sisteme similare, în timp ce 
1 doua are în vedere cerinţele beneficiarului. Orice clasă a modelului domeniului îşi regăseşte 


pu e i 


originea în experiența cunoscătorilor domeniului. Orice element al modelului afacerii (entitate 
sau unitate de lucru) îşi regăseşte originea într-o cerință a beneficiarului. Acesta este şi 
motivul principal pentru care utilizând cele două abordări, în mod normal, se obțin diferite 
clase, atribute, metode şi asocieri. 

O altă deosebire ar fi că pornind la analiza domeniului vom obține mai multe 
informaţii despre atributele claselor şi mai puține despre comportamentul acestora (clasele 
domeniului vor fi sărace în metode). Evident în cazul modelării afacerii se vor identifica atât 
entităţile şi unităţile de lucru (clasele), cât si utilizatorii (si operaţiile pe care aceştia le 
întreprind). 

Şi nu în cele din urmă, modelul afacerii fiind mult mai detaliat va fi mai bine 
valorificat în etapele ce vor urma. Se pot identifica mai bine actorii şi cazurile de utilizare ale 
sistemului proiectat, si fiecare dintre acestea va putea fi mai bine pus în corespondență cu 
cerinţele sistemului. 

Dacă modelul mediului abordează cu precădere funcţionarea sistemului în contextul 
acestuia, modelul afacerii îşi focalizează atenţia asupra utilizatorilor şi a modului cum 
sistemul îi deserveşte. 


7.11.3. Modelarea cazurilor de utilizare 


Un model al cazurilor de utilizare este format din actori şi cazuri de utilizare. Un 
actor este o entitate externă ce interacționează cu sistemul (similar unei entităţi externe dintr-o 
diagramă de flux a datelor), Actorul este ceva sau cineva care schimbă informaţie cu sistemul. 
Un actor ne este obligatoriu să fie un utilizator uman. El poate fi şi un alt sistem sau un 
dispozitiv hardware (ex. monitorul) cu care sistemul nostru interacționează sau schimbă 
informaţii, 

Un caz de utilizare este o secvenţă de acţiuni iniţiate de un actor, surprinzând un 
anumit mod de a folosi sistemul. Nu trebuie făcută confuzie între actor al sistemului şi 
utilizator al sistemului. Un utilizator este oricine foloseşte sistemul. Un actor este un rol pt 
care utilizatorul îl poate juca. Numele actorului trebuie să indice acest rol. Un actor este un 
tip sau o clasă de utilizator. Același utilizator poate juca mai multe roluri. De exemplu, dacă 
domnul Y joacă două roluri, unul de instructor iar celălalt de consultant, va fi reprezentat ca 
instanță a unui actor numit Instructor şi ca instanţă a unui alt actor numit Consultant. 

Actorii fiind entităţi externe sistemului, ei nu pot fi descriși în detaliu. Identificarea 
actorilor ajută la identificarea cazurilor de utilizare — întrucât un caz de utilizare este inițiat de 
un actor. lată câteva întrebări la gare analistul de sistem trebuie să răspundă pentru a 
identifica cazurile de utilizare: 

~ Care sunt principalele acţiuni executate de fiecare actor? 

- Actorul va citi sau va actualiza informaţia din sistem? 

- Actorul va informa sistemul despre modificările petrecute în afara acestuia? 

- Actorul va fi informat de modificările din sistem? 

Să considerăm cazul unui sistem de înregistrare a studenţilor la cursurile oferite de un 
Centru de instruire. Entit&file externe sistemului sunt studentul care se înscrie la curs, secretara 
care face înscrierea studenţilor la cursuri, casiera care încasează contravaloarea cursurilor și 
ritual care predă cursurile. Cazurile de utilizare asociate sistemului sunt redate în figura 

Un caz de utilizare este iniţiat întotdeauna de un actor şi poate interacfiona si cu alți 
actori, nu numai cu cel care l-a iniţiat. Cazul de utilizare trebuie să redea o funcționalitate 
completă şi nu numai o anumită acţiune a unei funcţionalităţi. Transmiterea unui formular de 
înscriere la un curs este parte a procesului de înregistrare la curs deci va fi inclus în cazul de 
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pex în exemplul anterior etichetarea cu simbolul <<extends>> a asocierii dintre 


„înregistrare la curs special” extinde cazul „inregistrare la curs", adăugându-i noi acţiuni şi 
comportamente. unui student la un curs special necesită şi permisiunea 
insructoralui (acţiune suplimentară), pe lângă paşii normali de înscriere Ia orice curs. 

E Este evidenţiată si o relaţie de utilizare prin etichetarea cu simbolul <<uses>> a 
asocierii dintre cazul „înregistrare la curs” şi cazul „nepromovare cursuri obligatorii” ceea ce 
— semnifică faptul că un caz de utilizare foloseşte celălalt caz de utilizare atunci când sc 
„execută. Înscrierea la cursul Y nu este posibilă decât dacă studentul a promovat cursurile 
pregătitoare acestuia. Cazul la curs” foloseşte cazul „nepromovare cursuri 
obligatorii” pentru a verifica dacă studentul a promovat cursurile pregătitoare cursului Y. 


Fig. 7.44. Sistem de înregistrare studenți 


Diagrama cazurilor de utilizare arată care sunt toate cazurile de utilizare din sistem dar 
nu indică modul în care acestea sunt realizate de către actori. Modelul cazurilor de utilizare 
este completat de o descriere textuală a fiecărui caz de utilizare, accentul punându-se pe 
interacţiunea cu alţi actori si mai puţin pe modul în care este executat în cadrul sistemului. 
Descrierea cazului de utilizare „Înregistrare la curs" sub forma unei succesiuni de paşi se face 
Ca în figura 7.45: 


Cazul de utilizare: inregistrare la curs. 
Actori: Student, Secretară 
Descriere: 


Acest caz de utilizare se declanşează atunci când 
studentul solicită înscrierea la un curs. Secretara verifică 
dacă studentul a parcurs cursurile pregătitoare şi a 
promovat examenele respective. Dacă este vorba despre 
un curs special, secretara solicită studentului aprobarea 
instructorului. Secretara înregistrează studentul la curs. 

Fig. 7.45. Descrierea cazului de utilizare „Înregistrare la curs” 


m: 


Modelarea cazurilor de utilizare permite analiza cerințelor funcţionale ale 


cerințele utilizatorului se modifică în timpul dezvoltării, aceste modificări sunt vizibile ma 
întâi în modelul cazurilor de utilizare. Modificările în cazurile de utilizare implică modifici 
$i în celelalte modele. Şi reciproca este valabilă, adică în momentul în care se fac modii 

în modele, acestea trebuie să se reflecte și la nivelul cazurilor de utilizare. 


obiectelor) 


Diagrama claselor documentează structura statică a sistemului; mai exact precizează 
clasele care există şi relaţiile dintre acestea, nu şi modul în care interacționează pentru a 
asigura un anumit comportament. Diagrama claselor poate de asemenea evidenția gi alte 
aspecte ale structurii statice, cum ar fi pachetele care însă vor fi prezentate mai târziu în cadril 
acestui capitol. = 
i irea diagramei claselor presupune în primul rând identificarea claselor din 
sistem, acest proces reprezintă o parte esenţială a proiectării sistemelor orientate obiect, de” 
succesul acestuia depinzând în mare parte succesul proiectului. - * 
pct eoe desees s oni uode A cal sint 1 
- obiectele c din model trebuie să poată furniza întregul com; 1 
- un bun model al claselor conţine (pe cát posibil) clase stabile din domeniul 
obiectual, care mu depind de funcționalitatea particulară cerută la momentul 
proiectării. 4 
Poate fi utilizată orice tehnică de obţinere a claselor atâta timp cât modelul obținut 
respectă criteriile enunțate, Implicit dacă modelul obținut nu respectă criteriile nu va fi nimeni 
interesat de tehnica utilizată, oricât de profesionistă ar fi aceasta. 
Y În practică e puţin probabil să reusegti din prima. Clasele selectate în modelul 
proiectare se vor modifica pe parcursul desfăşurării procesului iterativ de dezvoltare & 


___ În literatura de specialitate se propun două metode: proiectarea orientată pe date (dats 
driven design) si proiectarea orientată pe funcfiuni (responsibility driven design). Primul ip 
de metode presupune identificarea tuturor datelor din sistem și împărțirea lor pe clase, înainte 
de a considera funcțiunile acestor clase. Tehnica identificării substantivelor este cea mai 
utilizată astfel de metodă. Al doilea tip de metode, orientate pe funcțiuni, presupune 
Paar funcţiunilor sistemului şi împărțirea lor pe clase, înainte de x conia 
Tehnica identificării substantivelor presupune doua etape: Y 
- Identificarea claselor candidate, selectând din specificarea cerințelor sistemului 
toate substantivele şi frazele substantivale (se consideră substantivele la singular $i 
nu se aleg fraze ce conţin „sau” ca unici candidaţi). 
- Se elimină candidaţii consideraţi nepotriviţi din diverse motive şi se re 
clasele rămase dacă este necesar. 


Baze de date orientate obiect 


Unele dintre motivele pentru care o clasă candidată ar putea fi considerată nepotrivită 


* _- Redundanţa — o clasă e prezentă sub mai multe denumiri. Este important să ne 
amintim insă că obiecte similare pot să nu fie identice, Proiectantul decide dacă 
lucrurile sunt suficient de diferite pentru a merita clase diferite. De exemplu, dacă 
a fost selectată o pereche de genul imprumut” şi „împrumut pe termen scurt”, 
acestea sunt diferite, dar numai la nivelul valorii atributelor. Se recomandă în acest 
caz alegerea unui nume care să desemneze întreg conţinutul clasei. 

- Imprecizia — când nu se poate spune precis ce care e realitatea descrisă de 
substantivul respectiv. Desigur, trebuie îndepărtată ambiguitatea înainte de a putea 
spune dacă substantivul reprezintă o clasă. 

- Eveniment sau operaţie — când substantivul se referă la ceva ce este făcut de 
sistem. Uneori această situaţie este bine modelată de o clasă, dar nu este acesta 
cazul obișnuit. 

. Metalimbaj — unde substantivul face parte din modul de definire a cerințelor. Vom 
utiliza substantive ca „cerinţe” sau „sistem” ca parte a limbajului de modelare şi nu 
pentru a reprezenta obiecte din domeniul problemei. 

- Extern sistemului — atunci când substantivul este relevant pentru a descrie 
funcționarea sistemului, dar nu se referă la ceva din interiorul său. 

E ‘Atribut — atunci când este clar că substantivul desemnează o realitate simplă, fără 
un comportament interesant, care este de fapt un atribut al altei clase. „Numele” 

unui client ar putea fi un astfel de exemplu. 


Fig. 7.46. Diagrama claselor pentru sistemul de gestiune a comenzilor 


Diagrama obiectelor modelează instanțele elementelor conţinute în diagramele de 
clase. O diagramă obiectuală arată un set de obiecte şi relaţiile dintre acestea la un anumit 
moment. Diagramele obiectuale conțin obiecte şi legături. Ca și celelalte diagrame, poate 


md p — 


a A p 


conţine note si restricţii. Mai pot conţine anumite pachete sau subsisteme, fiecare fiind 
folosite pentru a grupa elementele modelului. Aceste diagrame se folosesc pentru modelarea 
statică a unui sistem, ca diagramele de clase, dar din perspectiva unor instanțe reale sau 
prototip. 

Crearea unei diagrame conceptuale se face intr-un singur mod, modelând structura 
obiectelor. Modelarea structurii obiectelor implică fotografierea obiectelor din sistem la un 
anumit moment. 

In figura 7.46. se prezintă o posibilă diagramă a claselor pentru un sistem de gestiune a 
comenzilor. Unii dintre clienţi pot beneficia de credit comercial, dar alţii trebuie să achite 
înainte de livrarea comenzii (aceia pentru care operația ClientEvaluareSituatie returnează 
valoarea „slabă”). 


7.11.5. Modelarea dinamicii sistemului 


Pentru modelarea dinamicii sistemului, UML furnizează două tipuri de diagrame, si 
anume diagramele de interacţiune (diagrama de secvenţă și diagrama de colaborare) și 
diagramele de comportament (diagrama de stare si diagrama de activitate) . Principala menire 
a acestor diagrame este de a arata cum realizează sistemul un caz de utilizare sau un scenariu 
particular dintr-un caz de utilizare. Pentru fiecare caz de utilizare se pot realiza mai multe 
scenarii (din descrierea cazului de utilizare). Pentru fiecare astfel de scenariu se pot întocmi, 
nu este obligatoriu, o diagramă de secvență sau o diagramă de colaborare (unele dintre 
instrumentele CASE pot obține o diagramă din alta). 1 

Acest tip de diagrame înlesneşte înțelegerea cazurilor de utilizare mai dificile. Ele pot 
de asemenea susține comunicarea în cadrul echipei de proiectare, în cazul în care de o aceeași 
interacțiune se ocupă mai multe persoane sau grupuri de persoane. Nu e de așteptat să se 
dezvolte astfel de diagrame pentru fiecare caz de utilizare sau pentru fiecare operaţie, doar 
dacă beneficiile depăşesc costurile. În cazul în care se dispune de un CASE ce poate utiliza 
aceste diagrame la generarea de cod, atunci devine profitabil să dezvoltam diagrame de 
interacţiune şi diagrame de comportament. 

Diagramele de secvență descriu modul în care obiectele interacționează si comunică 
între ele. Aceste diagrame permit focalizarea atenţiei asupra secvenfelor de mesaje, mai precis 
asupra mesajelor care sunt trimise şi recepționate de către obiecte. 

Avantajul major al diagramelor de secvenţă, faţă de diagramele de colaborare este 
posibilitatea de a reprezenta grafic trecerea timpului, fiind deci indispensabile in cazul 
proiectării de sisteme în timp real. 

În figura 7.47 este reprezentat un scenariu al cazului de utilizare „Comandă articole” 
dintr-un sistem de comerţ electronic. Scenariul presupune că validarea utilizatorului se 
finalizează cu succes şi că există un stoc nelimitat de produse, 

Diagramele de colaborare permit evidențierea atât a interacțiunilor cât şi a legăturilor 
dintre un set de obiecte care colaborează. Atât diagramele de secvență cát şi cele de 
colaborare vizualizează interacţiunile, dar diagrama de secvenţă ia în considerare timpul, pe 
când cea de colaborare, spaţiul. 

Ca si diagramele de secvență, diagramele de colaborare pot fi utilizate pent 
descrierea execuţiei unei operaţii, a unui caz de utilizare sau a unui scenariu de interacţiune in 
cadrul sistemului. în acest tip de diagramă nu pot fi descrise mesajele concurente şi asincrone. 
Pentru a putea realiza o comparare a celor două tipuri de diagrame în figura 7.48. a fost 
reprezentat acelaşi scenariu ca şi în figura 7.47. 
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Fig. 7.48. Reprezentarea unui scenariu cu ajutorul diagramei de colaborare 


Până acum nu am amintit nimic despre modelarea "deciziei" unui obiect despre ceea 
$ sa facă la primirea unui mesaj. Diagramele de interacţiune pot reprezenta obiecte diferite 
ale aceleiaşi clase care primesc același mesaj, dar răspund diferit. Acest comportament este 
i*zonabil de cele mai multe ori întrucât comportamentul unui obiect poate fi afectat şi de 
Valorile atributelor sale. Pentru a putea implementa, întreține sau testa o clasă este necesar să 

em relațiile de dependență care există între starea unui anumit obiect şi reacţiile sale la 
„Mesajele primite sau la alte evenimente. Diagramele de stare sunt acelea care înregistrează 
keste dependențe. 
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Pornind de aici, se pot folosi aproximativ aceleaşi notații pentru a descrie acti 
complexe. Se consideră că trecerea de la o activitate la alta atunci când prima activitate 
încheiat este similară cu trecerea unui obiect dintr-o stare într-alta, semnificativ diferită 
prima, atunci când acesta primeşte un mesaj Diagramele de activitate sunt o varialiune y 
diagramelor de stare, adaptate pentru a evidenția conexiunile şi dependentele dintre activit 
Ele sunt extrem de folositoare atunci când se apreciază că o activitate trebuie să execute g 
serie de task-uri diferite şi dorim să modelăm dependentele esenţiale dintre acestea, înainte de 
a decide în ce ordine să se execute. 5 


Diagramele de stare au rolul de a captura ciclul de viaţă al obiectelor, subsistemelor şi 
sistemelor, prin specificarea stărilor în care se poate găsi un obiect si a evenimentelor (mesaje 
primite, erori, condiţii care devin adevărate) care-i afectează starea de-a lungul execuției, 0 
diagramă de stare poate fi atașată oricărei clase care are stări clar identificabile gi uy 
comportament complex. 

Presupunând că este vorba despre un sistem contabil, diagrama ce descrie 
comportamentul clasei „Factură” este reprezentată în figura 7.49, 

Creare faciunt USA 


We | Pa Distrugere factu 


Fig. 7.49. Diagramă de stare > 

O diagramă de activitate constituie o variantă a diagramei de stare, cu un scop puțin 

diferit, acela de a evidenția acțiuni şi rezultate ale acestor acțiuni. De fapt, diagramele de 

activitate constituie o cale altermativà de descriere a interacțiunilor, cu posibilitatea de 

specificare a acțiunilor care se vor realiza, prin precizarea următoarelor elemente: s 

Ce fac acţiunile? (modificările stărilor obiectului), x 

- Când au loc acţiunile? (secvenţa de acţiuni) si $ 

- Unde au loc acţiunile? a 

de activitate pot fi utilizate şi pentru a descrie cum se desfăşoară cazuri de 

utilizare individuale şi cum depind de alte cazuri de utilizare. 3 
i de activitate pot fi folosite în mai multe scopuri şi anume: $ 

Ilustrarea acţiunilor care vor fi realizate atunci când este executată o operație. 

Acesta este şi cel mai comun caz de utilizare a acestui tip de diagramă. 

Prezentarea activităţii interne a unui obiect. " 

Identificarea acţiunilor, care pot fi realizate în mod legat şi stabilirea modului în 

care aceste seturi de acţiuni afectează obiectele din jur. $ 

Ilustrarea modului in care instanța unui caz de utilizare poate fi realizată în 

termenii acţiunilor sau modificărilor intervenite în starea obiectului. 3 
- Mustrarea modului în care este organizată munca actorilor, care este organizarea 

obiectele folosite, | 


Activităţile realizate la biroul de  recepiie a unui hotel se pot modela cu ajutorul, 
diagramei de activitate astfel (figura 7.50.): 3 


Fig. 7.50. Diagrama de activitate pentru recepţia unui hotel 


7.12. Proiectarea BDOO — componentă a sistemului 
informatic 


Este iut faptul că orice sistem informatic sau aplicaţie informatică ce operează cu 
Volume mari de dale face apel la un mod seu altul de organizare a datelor. De modul de 
organizare a datelor depinde în mare măsură şi performanțele sistemului informatic. 
Organizarea datelor în baze de date orientate obiect constituie cel mai evoluat mod de 
organizare. Într-o astfel de situație se poate spune că BDOO constituie o componentă 
semnificativă a sistemului informatic iar proiectarea acesteia are loc în cadrul general de 


În activitatea de proiectare a BDOO pentru aprovizionarea cu materii prime şi 
materiale vom adopta varianta de proiectare plecând de la identificarea/cunoaşterea cerințelor 
sistemului în funcție de care vom recurge la identificarea claselor de obiecte cu structura 


Tn concordanța cu UML succesiunea pasilor de urmat va fi: modelarea proceselor de 
afaceri, modelarea cazurilor de utilizare şi modelarea structurii statice a sistemului. 
7.12.1. Modelarea proceselor de afaceri 
i preci in modelarea proceselor de afaceri se va urmări 
a eri ned de ien a proceselor ocazionate de activitatea de 


aprovizionare cu materii prime si materiale pentru îndeplinirea planului de producție. 
Sinteza şi succesiunea logică de derulare a acestor procese este redată în figura 7.51. 
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PLAN APROVIZIONARE 
DE MATERII PRIME 


REPERE 
ACHIZIȚIONATE 
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DERULARE 
CONTRACTARE 


Fig.7. 51. Diagrama sintetică a fluxului informaţional pentru activitatea de aprovizion®® 
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RECEPȚIA MATERII 
PRIME 


EXPEDITIE. 


FIŞA LIMITA 


Fig. 7.52. Diagrama de detaliu a fluxului informaţional pentru 
activitatea de aprovizionare 


, Din schema prezentată pot fi reținute două aspecte esenţiale si am 
succesiunea logică a proceselor iar, pe de altă parte, faptul că pa d pasta. 
separat pentru achiziţionarea de repere şi separat pentru achiziționarea de materii prime Și 
materiale necesare confecţionării reperelor prin producție proprie. 

În figura 7.52. sunt redate într-o formă mai detaliată aspectele cu privire la activitatea 

de aprovizionare. Urmărind figura 7.52. pot fi deduse trei aspecte esențiale şi anume: 5 
~ pe axul schemei sunt precizate procesele de afaceri (proceduri), 

- pe partea din stânga axului schemei sunt specificate intrările sistemuld 
(documente primare sau alte surse de intrare) pe baza cărora se cfectuci 
procedurile, Fi 

- pe partea din dreapta axului schemei sunt specificate iesirile sistemi 

z M ad primare de ii) arcis ale procedurilor efectuate. 

le ce vom căuta să o scurtă prezent proceduri] 
în figura 7.52, fără a avea pretenția unei lecţii de o ama am a 
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Baze de date orientate obiect 


Elaborarea planului şi graficului de desfacere luând în considerare ca intrări 
informaţiile preluate din nomenclatorul de produse finite, stocurile de produse 
finite existente, contractele sau comenzile ferme încheiate cu beneficiarii precum 
şi capacităţile de producție. Ca rezultate ale procedurii se vor obține Planul de 
desfacere şi Graficul de desfacere. 

Elaborarea planului de producţie având ca intrări Planul de desfacere, Graficul de 
desfacere şi alte informaţii, rezultând ca ieşire Planul de producţie. 

Determinarea structurii produsului finit pe baza informaţiilor preluate din Fişa 
produsului şi Planul de producţie rezultând Situaţia necesarului de repere. 

Pe baza Situaţiei necesarului de repere se va proceda la determinarea necesarului 
de repere de achiziționat şi necesarului de repere obținute din producţie proprie. 
Planul de aprovizionare va fi elaborat separat pe cele două categorii de repere aşa 
cum se sugerează si în figura 7.51. 

Determinarea necesarului de materii prime pentru reperele din producţia proprie 
pe baza informaţiilor de intrare preluate din Situaţia necesarului de repere, Planul 
de producţie, Fişa produsului (consumurilor specifice de materii prime pe reper) si 
Fişa tehnologică rezultând ca ieşire Situaţia necesarului de materii prime. 
Determinarea necesarului de aprovizionare şi elaborarea Planului si Graficului 
de aprovizionare, ținând seama de Situaţia necesarului de materii prime, Situaţia 
stocurilor existente şi preliminare (finale). 

Identificarea furnizorilor potențiali. Pe baza Situaţiei necesarului de materii prime 
şi a informaţiilor despre furnizorii potenţiali preluate din „Baza de date - 
furnizorii” va fi elaborată Situaţia furnizorilor potențiali. 

Lansarea cererilor de oferte. Pe baza informaţiilor privind Situaţia furnizorilor 
potenţiali se va proceda la lansarea cererilor de oferte. Cu cât vom cunoaşte mai 
mulți furnizori potenţiali si cărora le vom lansa cereri de ofertă cu atât vom avea 
şanse sporite de a realiza o tranzacție comercială mai „fericită” (mai avantajoasă). 
Alegerea ofertei optime făcând apel la un model de alegere bazat pe teoria 
deciziilor multicriteriale, cum ar fi metoda Von Neumann-Morgenstern, 
ELECTRE sau o alta dintre cele cca. 20 existente. 

Se va obține Situaţia comparativă a ofertelor (Matricea decizională), care nu 
înseamnă altceva decât un clasament al ofertelor realizat pe baza punctajului 
global (criteriu global) acordat fiecărei oferte, luând în considerare o serie de 
Criterii cu ponderi de importanță diferențiate. Procedura poate fi extinsă cu 
simularea tratativelor comerciale, modificând valorile anumitor parametrii din 
cadrul Matricei decizionale ca urmare a unor facilităţi scontate a fi dobândite pe 
parcursul desfăşurării tratativelor comerciale. Cu modificările astfel efectuate se 
întocmeşte noul clasament al ofertelor. Vor fi reţinute primele două sau trei oferte 
mai bine clasate, pentru care se vor purta tratative comerciale cu furnizorii. În 
funcţie de rezultatele obţinute în urma negocierilor se va alege oferta optimă. 
Contractarea şi perfectarea contractului. Pentru oferta optimă se va elabora 
contractul care apoi va fi perfectat de către factorii de decizie ai unităţii beneficiare 
şi furnizoare. 

Derularea contractelor/lansarea comenzilor de aprovizionare în concordanță cu 
Planul de producție şi Graficul de aprovizionare. 

Recepţia materiilor prime pe baza Facturii sau Avizului de expediţie şi întocmirea 
NIR. NIR-ul va constitui documentul justificativ pe baza căruia se va opera, pe de 
o parte asupra stocurilor de materii prime iar, pe de altă parte, se va consemna 
intrarea de materii prime în contabilitate „Rulaje intrări”. 


- Darea în consum a materiilor prime pe baza Fisei limită de consum sau Bonurilor 
de consum. Totodată se va opera în Rulajul iegirilor și asupra Stocurilor cu 


diminuarea acestora corespunzător cantităților eliberate. i inte 
Observaţie. În mod asemănător se va proceda şi pentru achiziționarea reperelor. 
Elaborare plan 
B producție 
7.12.2. Modelarea cazurilor de utilizare E P 


Pe baza modelării proceselor de afaceri au fost desprinse cazurile de utilizare a căror 
diăgrame sunt redate în figura 7.53, astfel: 
— Elaborarea planului de desfacere, 
— Elaborarea planului de producție, 
- Determinarea structurii produselor pe repere, 
— Determinarea necesarului de materii prime pentru repere din producție internă, 
— Determinarea necesarului de aprovizionat, 
—  Prospectarea pieţei 
Identificarea furnizorilor potențiali, 
* Lansarea ofertelor, 
* Primirea ofertelor 
- Contractarea 
= Evaluarea ofertelor, A 
= Simularea tratativelor comerciale, 
* Alegerea ofertei optime 
— Perfectarea contractelor, 
— Derularea contractelor, 
— Lansarea comenzilor, 
- Recepția materialelor 
= Acceptare, 
» Refuz parțial 
» Refuz total 
— Înregistrarea în fișa de magazie, 
— Achitarea facturilor 
* Achitare parțială, 
* Achitare totală 
— Înregistrarea în contabilitate. 
Pentru fiecare caz de utilizare se precizează denumirea si actorii ce declanșează cazul 
de utilizare. Pot fi observate situaţiile în care un actor participă la unul sau mai multe cazuri 


de utilizare sau situaţia în care la un caz de utilizare participă unul sau mai mulți actori. [M 
Totodată, in figura 7.53. pot fi observate utilizarea relațiilor de generalizare (situaţiile Attila 
Refuz marfă şi Achitare facturi), de incluziune <include> sau de extensie <extend> între comerciale 
cazuri de utilizare. 
De remarcat faptul că fiecare caz de utilizare poate fi extins cu o descriere detaliată pe 
baza căreia să poată fi elaborate alte tipuri de diagrame necesare. Alegerea ofertei 
optime 


M C 
DESFACI 
=) 
CANT-COMANDATĂ 
1+ 


b. cram F 
jurist 1 
beneficiar : 
Lansare i 
comenzi f 
(extend » 2s «extend» 
A ! 
Derulare 
c. 
A 
cenid» 
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FA 
Fig. 7.54. Diagrama claselor de obiecte — Modelul static 


pem p p p vc m 


Baze de date orientate obiect 


SECTIE-PROD. di 


-den. secţie: string 
- gef secție: string 


i + creare () 
à + adăugare ( ) 
= + ştergere () 
Fi + modificare () 
i COMANDA - MATERIAL 
* cod mat.: number 
3 nr. comandă: number 
Š cant. comandă: integer 
cant.-livrată: integer 
GESTIUNE ternem-livrare: integer 
- den-gestiune: string | =A 
-cod-gestiume: integer * creare () 
- nume-gestionar: string s + modificare ( ) 
- garant-gest: number (x adăugare ()____| 


+ creare gest () 
+ actualizare () 


pe 


- stoe-siguranţă: 
= stoc-exist: 


+ cale, stoc, ex. () 
+ calc. imobilizări () 

+ cale-necesar-aproviz. () 
+ actualizare 


NIR BON CONSUM 
-nr. NIR: number Ne. bon: number 
- data NIR: date - data bon: date 
= cant, recepi: ^ — integer - cant. eliberată: integer 
creează () + creare () 
+ vizualizează + adăugare () 
+ vizualizare () Fig. 7.55. Clasele de obiecte — modelarea claselor de obiecte 
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7.12.3. Modelarea structurii statice a sistemului 

Rezultatul modelării structurii statice va consta în „Modelul static" care va — 
reflecta multitudinea claselor de obiecte cu asocierile dintre ele. Clasele de obiecte pot fi 
identificate din modelarea proceselor pe baza diagramelor cazurilor de utilizare. 

Pentru exemplul de referinţă, clasele de obiecte şi diagrama acestora sunt redate în 
figura 7.54. Din considerente de lipsă de spaţiu, descrierea detaliată a fiecărei clase este 
redată separat în figura 7.55. 

Diagrama claselor de obiecte astfel elaborată poate fi completată şi cu alie ^ 
elemente desprinse din modelarea dinamică pe baza altor tipuri de diagrame. În final, - 
diagrama claselor de obiecte poate fi transpusă într-un limbaj de programare | 
corespunzător, rezultând astfel structura bazei de date orientate obiect pentru activitatea 
de aprovizionare cu materii prime si materiale. 


7.13. RUP-suport de realizare a sistemelor z 
informatice şi implicit a BDOO 


Rational Unified Process (RUP) este un proces general pentru dezvoltarea 
orientată obiect de produse informatice. Este un ghid care arată cum se poate utiliza 
practic UML (Unified Modeling Language) pentru a dezvolta un sistem informatic. H 

In RUP ciclul de viaţă al proiectului unui sistem informatic este descompus in — 
patru faze, fiecare având asociat un rezultat final (determinarea obiectivelor, definirea 
arhitecturii, implementarea funcționalități şi lansarea finala). La sfârşitul fiecărei faze 
este efectuată o analiză pentru a determina dacă obiectivele au fost îndeplinite. Trecerea Ed 
la următoarea fază se realizează numai în momentul satisfacerii obiectivelor fazei — 
curente. Fazele descrise de RUP sunt: explorarea lá, elaborarea, construcţia şi 
tranziţia (figura 7.56.. Pe parcursul fiecărei faze se desfăşoară procese primare 
(identificarea cerinţelor, analiza sistemului, proiectarea sistemului, implementarea şi 
testarea) şi procese suport (managementul proiectului, managementul schimbării, 
controlul mediului). În ceea ce priveşte procesele primare, în fazele iniţiale predomină 
procesele de identificarea cerinţelor şi analiză. Pe măsura dezvoltării iterative a fazelor 
accentul se mută succesiv pe proiectare, implementare şi testare. Procesele suport sunt 
prezente într-o proporţie constantă pe parcursul ciclului de dezvoltare, cu excepția 
procesului de management al schimbării. Acesta este mai scăzut în fazele iniţiale (când 
modificările nu sunt cazuri de excepție, ci mai degrabă regula) dar îşi intensifică prezența 
în final, când necesitatea unci modificări trebuie atent analizată şi integrată pentru a nu 
periclita succesul proiectului (cu cât proiectul este mai avansat cu atât este mai dificil de 
realizat modificări). 
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PROCESE PRIMARE 
Identificarea cerințelor 


EXPLORARE ELABORARE 


Implementarea 
Testarea 
PROCESE SUPORT 
Managementul proiectului 
Managementul schimbării 
Controlul mediului i 


7.13.1. Cele mai bune practici de realizare a sistemelor 
informatice 


Un proces este un o succesiune ordonată de paşi necesari pentru atingerea unui 
obi În cazul industriei software scopul este realizarea unui nou produs software sau 
dezvoltarea unuia existent. RUP descrie o familie de subprocese corelate care folosesc o 
structură si o arhitectură comună. Scopul procesului este acela de a asigura crearea unui 
sistem informatic robust care îndeplineşte criteriile impuse de utilizator, într-un orizont 
de timp predictibil și în limitele bugetului alocat. Din acest punct de vedere RUP respectă 
întocmai teoria clasică a managementului proiectelor care insistă asupra acestor trei 
restricţii: calitate, timp şi buget. RUP surprinde cele mai bune practici folosite in industria 
software (dezvoltarea iterativă, managementul ceringek arhitectura bazată pe 
componente, modelarea vizuală, verificarea continuă a calit controlul schimbărilor ) 
intr-o formă care poate fi adaptată pentru o plajă foarte largă de proiecte si organizaţii. De 
asemenea, RUP îmbunătăţeşte comunicarea în cadrul echipelor descriind un limbaj şi un 
proces comun pentru toate persoanele implicate în proiect. 

Unified Process descrie cum pot fi aplicate efectiv practici care s-au dovedit a fi 
eficiente pentru echipele de dezvoltare software. Am utilizat acest termen de „cele mai 
bune practici” nu atât pentru că ar fi uşor de cuantificat valoarea lor, ci pentru că sunt 
practici utilizate în mod obişnuit de organizaţiile de succes din industria software, 


Dezvoltarea iterativà. Abordarea tradiţională în care se parcurg secvențial etapele 
de definire a problemei, analiză, proiectare, realizare şi testare pare să nu mai fie cea mai 
potrivită dată fiind complexitatea actuală a sistemelor informatice. Este necesară 
dezvoltarea iterativă care asigură o mai bună cunoaştere şi înțelegere a problemei pe 
măsură ce soluția efectivă se dezvoltă pe parcursul a mai multor iterații. RUP suportă o 
astfel de abordare iterativă care permite tratarea elementelor cu un grad ridicat de risc la 
fiecare etapă a ciclului de dezvoltare al proiectului, ceea ce reduce semnificativ riscul 
întregului proiect. Riscul pe ansamblu este combătut prin realizarea frecventă de versiuni 
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executabile ale sistemului prin care se poate obţine implicarea și feedback-ul 
beneficiarului. Întrucât fiecare iterajie se finalizează cu o aplicaţie executabilă echipa 
rămâne concentrată pe rezultate, iar verificárile frecvente de stare asigură încadrarea in 
timp. Dezvoltarea iterativă asigură şi o mai bună integrare a modificărilor care apar 
ulterior în cerințe, funcționalitate sau planificare. 


Managementul cerințelor. RUP descrie cum se pot obține, organiza si documenta 
cerințele funcționale şi restricțiile, cum se pot urmări negocierile şi deciziile, cum se pot 
identifica si comunica cu uşurinţă cerințele procesului de afaceri. Noţiunile de caz de 
utilizare şi scenariu s-au dovedit instrumente deosebit de eficiente în identificarea 
cerințelor funcționale si transmiterea acestora la nivelul proiectării, implementării si 
testării produsului software, ceca ce a crescut considerabil şansele ca produsul final să 
corespundă nevoilor beneficiarului. Cu ajutorul cazurilor de utilizare se pot verifica atât 
pe parcurs cât si în final respectarea cerințelor formulate de beneficiar. 


Arhitectura bazată pe componente. Procesul se concentrează pe realizarea cât mai 
devreme a unei arhitecturi robuste executabile, înainte de alocarea tuturor resurselor 
pentru dezvoltarea aplicaţiei. Structura dezvoltată în fazele iniţiale va constitui nucleul pe 
care se va dezvolta sistemul în continuare. RUP descrie cum se poate dezvolta o 
arhitectură flexibilă, adaptabilă, uşor de înţeles si care să susţină utilizarea efectivă a 
reutilizării. UP suportă dezvoltarea orientată pe componente. Componentele sunt module 
non-triviale, subsisteme ce îndeplinesc o funcţie clară. RUP oferă posibilitatea definirii 
unei arhitecturi pe baza componentelor existente si a altora noi. Acestea sunt asamblate 
într-o arhitectură bine definită ad-hoc sau într-o infrastructură bazată pe componente cum 
ar fi Internet, CORBA şi COM (pentru care există o industrie înfloritoare de componente 
reutilizabile). 


Modelarea vizuală. RUP promovează modelarea vizuală a structurii și 
comportamentului arhitecturii si componentelor sistemului. Mediile speciale de proiectare 
asistată (CASE) oferă posibilitatea verificării continue a consistenfei şi completitudinii 
modelului proiectat. Utilizarea standardului UML, creat de Rational Software, reprezintă 
certitudinea unei modelări vizuale de succes. 


Verificarea calităţii. Performanţe şi fiabilitate scăzută a aplicaţiilor este motivul 
principal pentru care proiectele software sunt refuzate. Astfel calitatea trebuie verificată 
pe parcurs insistând asupra fiabilităţi, funcționalități, performanţelor aplicaţiei (software 
$i hardware). RUP asistă dezvoltatorul în planificarea, proiectarea, implementarea, 
execuţia și evaluarea acestor teste. Evaluarea calităţii este integrată în proces, în toate 
activităţile, implică toţi membrii echipei, utilizează obiective măsurabile şi criterii, ea nu 
este tratată ca o activitate separată ce trebuie să se desfăşoare la final de către un grup 
restrâns de oameni. 


Controlul schimbărilor. Posibilitate de gestiune eficientă a schimbării — 
asigurarea unui mediu în care orice schimbare e posibilă şi posibilitatea de a urmări 
schimbările făcute — este esenţială într-un mediu în care schimbarea e inevitabilă. RUP 
asigură controlul, urmărirea şi monitorizarea schimbărilor. 
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Baze de date orientate obiect 
i 7.13.2. Individualizarea RUP 
= 
$ Dintre toate cele menționate mai sus, procesul unificat de dezvoltare 
T0 Dime de software 
este individualizat de trei sintagme - orientat pe cazuri de ilizare, centrat itectura 
£ sistemului, iterativ si incremental. » S e 
3 
= 
$ Proces orientat pe cazuri de utilizare 
$ Scopul central al unui sistem informatic îl reprezintă satisfacerea cerințelor 


utilizatorilor. Fie că acesta aduce noi funcționalități sau doar îmbunătăţeşte funcţionalităși 
existente el se dezvoltă pornind de la cerințele utilizatorilor. Dacă dorim un m i 
fie apreciat drept performant trebuie să acordăm o atenţie deosebită identificării acestor 


cerințe. 


— 


utilizatorul uman. Orice 
ts 4 să-l construim este ur 
utilizator din punctul de vedere al sistemului nostru. Un exemplu de astfel de insecte 
ar putea fi considerată efectuarea unei rezervări prin intermediul unui istem de rezervări 
on-line. Persoana interesată solicită o rezervare, în urma unui schimb de informaţii între 
utilizator şi sistem (persoana își defineşte mai precis cererea, sistemul de rezervare 
prezintă mai multe opțiuni posibile), dar si în urma unei verificări a cărții de credit 
(verificare ce este făcută de un alt sistem specializat, utilizator al sistemului de rezervare) 
se obține confirmarea de rezervare, O astfel de interacţiune poartă denumirea de caz de 
utilizare. Un caz de utilizare reprezintă o funcționalitate a sistemului care fumizează un 
rezultat uti Cu ajutorul cazurilor de utilizare se surprind cerințele funcţionale 
ale sistemului. Totalitatea cazurilor de utilizare formează modelul cazurilor de utilizare, 
incionalite a sistemului. 


Ce trebuie să facă sistemul pentru fiecare dintre uti 
„Este important de precizat faptul că modelul cazurilor de utilizare nu este doar un 
instrument de identificare a cerinlelor, ci el urmează să dirijeze întreg procesul de 
dezvoltare software, controlând proiectarea, implementarea și testarea sistemului. Pe 
parcursul întregului proces modelul cazurilor de utilizare rămâne ca un model de 
referință, proiectanți dezvoltă modele care implementează cazurile de utilizare, verifică 
modelele succesive şi conformitatea acestora cu modelul cazurilor de utilizare, iar testerii 
se asigură că modelul de implementare respectă funcțiunile cazului de utilizare, În acest 
mod cazul de utilizare nu este doar un punct de pornire ci este elementul de legătură al 
„Procesului unificat de dezvoltare. Cazurile de utilizare sunt specificate, apoi proiectate și 
= în final sunt sursă de construire a modelelor de testare. La fel de adevărat este însă că ele 
m sunt alese independent ci în corelaţie cu arhitectura sistemului. Cazurile de utilizare 
join o anumită arhitectură, iar arhitectura sistemului influențează selectarea cazurilor 
i Slizare, astfel cele două se dezvoltă în tandem pe măsura parcurgerii ciclului de viaţă 
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Proces centrat pe arhitectură 

Rolul arhitectului de sistem este similar aceluia de arhitect într-un proiect de 
construcții. Arhitectul surprinde clădirea din mai multe puncte de vedere: structură, 
amenajări, detalii, instalaţii şi toate acestea permit constructorului să aibă o imagine de 
ansamblu asupra clădirii înainte ca aceasta să fie construită. În mod similar arhitectul de 
sistem descrie din diferite puncte de vedere sistemul ce urmează a fi construit. 

Arhitectura de sistem cuprinde cele mai semnificante aspecte statice şi dinamice 
ale sistemului. Arhitectura sistemului Îşi are originea în cerințele utilizatorilor, reflectate 
în cazurile de utilizare, dar este influențată de mult mai multe aspecte, cum ar fi: 
platforma software pe care va rula aplicaţia (arhitectura calculatoarelor, sistemul de 
operare, sistemul de gestiune a bazei de date, 
utilizate), blocuri reutilizabile disponibile (GUI, DAO), consideraţii de structură, 
reglementări legale, cerințe nefuncţionale (performanţă, fiabilitate). Arhitectura este o 
imagine a întregului proiect ce evidenţiază părțile esenţiale, ignorând detaliile. Cum 
identificarea a ceea ce este esenţial se face în mod subiectiv, calitatea arhitecturii 
sistemului depinde de experiența celor implicaţi în realizarea ei. Cu toate acestea, 
procesul unificat stabileşte obiective de urmat pentru a optimiza calitatea arhitecturii 
sistemului (lizibilitate, ușurință în modificare, reutilizare). 

Aşa cum am mai evidenţiat în paragraful precedent, cazurile de utilizare şi 
arhitectura sunt puternic legate. Orice produs are o funcţiune şi o formă, în cazul 
produselor informatice cazurile de utilizare reprezintă funcţionalitatea produsului, iar. 
arhitectura, forma acestuia. Cele două părți trebuie armonizate pentru a obţine un produs 
calitativ, Funcțiunea însă, poate determina o anumită formă (în cazul proiectului de 
construcții dacă se dorește realizarea unei săli de sport aceasta implică o formă 
predefinită) si forma poate restricționa funcțiunea (după 1989 multe spaţii de locuit au 
fost amenajate ca spatii pentru birouri, faptul că ulterior a existat o cerere semnificativă 
de clădiri cu destinaţie de birouri susține faptul că reamenajarea, modificarea superficială 
a formei, nu a susținut modificarea funcțiuni). În aceeaşi măsură în cazul unui sistem 
software, cazurile de utilizare trebuie să se potrivească în arhitectură, iar arhitectura 
trebuie să ofere cadrul general de utilizare al tuturor cazurilor de utilizare, nu numai a 
celor iniţiale ci şi a cazurilor de utilizare posibile viitoare. Pentru a identifica acea formă 
care să permită sistemului să evolueze se practică identificarea funcţiunilor cheie ale 
sistemului, a cazurilor de utilizare cheie. Chiar dacă de cele mai multe ori acestea nu 
reprezintă decât 5-10% din totalul cazurilor de utilizare, ele reprezintă esența sistemului. 


Proces iterativ şi incremental. 


È 


Procesul de dezvoltare al aplicațiilor complexe din zilele noastre poate dura pánà | 
in 


la câţiva ani, motiv pentru care se practică în mod uzual împărțirea proiectelor 
subproiecte. Un subproiect reprezintă o iterafie si fiecare iteratie aduce un plus de valoare 
(un increment) produsului final. De la o iterație la alta produsul se îmbogățește, fie sub 
aspect calitativ (mai ales în fazele iniţiale ale proiectului, când se poate trece de la o 
abordare superficială la o abordare mai în detaliu), fie cantitativ (în fazele finale ale 
proiectului, cánd produsul dobândeşte noi funcțiuni). 

Fiecare iteratie tratează un set de cazuri de utilizare care împreună sporesc gradul 


de utilizare al produsului, dar şi riscurile specifice asociate proceselor respective. În ` 


cadrul fiecărei iterații se vor identifica şi specifica in detaliu cazurile de utilizare 
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corespunzătoare, se va trece la proi luând in considerare si arhitectura sistemului, se 
va implementa proiectul în componentele sistemului şi in final se vor testa componentele 
dacă îndeplinesc cerințele surprinse de cazurile de utilizare de la care s-a pornit. 

Avantajele unui astfel de proces iterativ sunt multiple. Dintre acestea amintim: 

- reducerea costurilor de neconcordanţă cu cerințele iniţiale; dacă la un moment 
dat este necesară reluarea unei iterații, atunci pierderile sunt limitate la 
costurile iteratici respective; 

- reducerea riscului de a lansa / finaliza produsul cu întârziere, prin identificarea 
din timp a riscurilor majore, În abordarea tradiţională abia în momentul 
testelor finale erau identificate probleme pentru a căror rezolvare proiectul era 
întârziat, 

- accelerarea în ansamblu a ritmului de dezvoltare al proiectului; echipa este 
mai bine focalizată pe rezultate şi pe respectarea unui plan pe termen scurt; 

- o mai bună implicare a beneficiarului, precum şi rafinarea iterativă a cerințelor 
acestuia. În plus acest mod de abordare permite un mai bun control al 
schimbărilor datorate atât mediului proiectului cât şi modificării specificaţiilor 
acestuia. 

lterajile se planifică iniţial şi rareori suportă modificări (ştiut fiind că orice 
abatere de la un plan inițial implică costuri suplimentare). Acest mod de abordare nu 
reprezintă o scuză pentru un management haotic si nu implică o dezvoltare aleatoare. 
Dezvoltare iterativă nu înseamnă reproiectarea la infinit a aceluiaşi modul până când in 
sfârşit se „nimereşte” o variantă care funcţionează. Aceasta reprezintă, din contră, un 
instrument de planificare ce reduce, încă din fazele iniţiale, riscurile ce ar putea afecta 
buna desfăşurare a proiectului. Versiunile intermediare permit obţinerea unui feedback 
din partea tuturor celor interesaţi de proiect şi corectarea din timp a eventualelor abateri 
înregistrate. 

Dacă am reprezenta evoluția riscului într-o abordare iterativă, faţă de evoluția 
riscului în cazul modelului de dezvoltare în cascadă, se observă că în abordarea iterativă 
riscurile majore sunt eliminate încă din fazele iniţiale ale proiectului, în timp ce în cazul 
modelului în cascadă riscurile scad substanţial abia în momentul integrării şi testării 
aplicaţiei figura 7.57. 

Conform RUP, pentru realizarea unui sistem informatic, trebuiesc parcurse în 
cadrul unei iterații următoarele procese primare: cerințelor, analiza, 


proiectarea, implementarea si testarea. În cele ce urmează vom prezenta mai pe larg 
conţinutul proceselor de identificarea cerințelor, analiză şi proiectare, Pentru 
exemplificarea diagramelor si tehnicilor de modelare UML a fost ales un sistem simplu 
de rezervare a biletelor pentru o linie aeriană. Au fost atinse următoarele probleme: 
organizarea sistemului utilizând pachete; 

identificarea cerințelor sistemului cu ajutorul cazurilor de utilizare; 


de date relationale. 
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Fig, 7.57. Controlul riscului în dezvoltarea incrementală 


7.13.3. Identificarea cerinţelor 


Principalele activităţi ce trebuiesc parcurse în această etapă sunt: 

~ Identificarea cerințelor candidate (in documentația de inițiere a proiectului, 
care în acest caz poartă denumirea de viziune); 

= Structurarea sistemului (utilizând 

-  Aprofundarea înţelegerii contextului (utilizând fie modelul mediului, fie 
modelul afacerii); 

- Identificarea cerințelor funcţionale (utilizând modelul cazurilor de utilizare); 

- Identificarea cerințelor non-funcționale. 


Identificarea cerinţelor candidate J 

În documentaţia de inițiere a proiectului (viziune) se identifică cerințe posibile 
pentru sistemul respectiv. Acestea se completează fie pe baza experienței, fie din notele 
de interviu sau alte documente. Cel mai important document pentru identificarea acestor 
cerinţe candidate rămâne viziunea. În cazul sistemului de rezervare cerinţele candidate ar 
putea fi: rezervarea de bilete direct la companie sau prin intermediari (agenti de turism). 
calculul automat al celei mai avantajoase rute (din punct de vedere al costului sau al 
timpului), gestiunea automată a situaţiilor speciale (anularea unei curse), 


Organizarea sistemului utilizând pachete . 

Una dintre sarcinile cheie ale model&rii sistemelor software de mari dimensiuni 
este împărțirea acestora in arii de mici dimensiuni, mai uşor de manevrat. Fie că se 
numesc domenii, categorii sau subsisteme, ideea de bază e aceeași: împărțirea sistemului 
în arii ce împărtăşesc o problematică similară. 
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UML introduce noțiunea de pachet ca entitate de grupare a elementelor, 
permițând proiectantilor să împartă și să clasifice sistemele complexe. Pachetele pot fi 
utilizate la orice nivel, de la cel mai înalt, unde sunt utilizate pentru a împărți sistemul în 
domenii, până la cel mai de jos nivel, unde se utilizează pentru a grupa cazuri de utilizare, 
clase sau componente. În RUP, ca şi în cazul altor metodologii orientate pe cazuri de 
utilizare, aceasta poate constitui o primă etapă. Sistemul de rezervare a fost structurat în 
cinci subsisteme (reprezentate printr-o diagramă a pachetelor, figura 7.58.): întreţinerea 
flotei, sistem de urmărire a zborurilor, sistem de rezervare, sistem contabil, personal. 


Fig. 7.58. Organizarea sistemului cu ajutorul pachetelor 


Identificarea cerinţelor sistemului cu ajutorul cazurilor de utilizare 
Modelarea cu ajutorul cazurilor de utilizare este tehnica cea mai uşoară si mai 
eficientă pentru identificarea cerințelor din perspectiva utilizatorului. Cazurile de utilizare 
sunt folosite pentru a modela modul de funcționare al sistemului actual sau modul de 
funcţionare al sistemului dorit de utilizatori. Nu utilizează o abordare orientată obiect, 
este mai degrabă o modelare a proceselor, dar cu toate astea este o tehnică excelentă de 
iniţiere a analizei orientată obiect a sistemului. Cazurile de utilizare: sunt în general 
— punctul de pomire în analiza orientată obiect utilizând UML. ~ 
< Diagrama cazurilor de utilizare constă din actori şi cazuri de utilizare, Actorii 
reprezintă utilizatorii şi alte sisteme ce interacționează cu sistemul analizat. Ele reprezintă 
în fapt un tip de utilizator şi nu o instanță a acestuia. Cazurile de utilizare reprezintă 
comportamentul sistemului, scenariile pe care acesta le execută ca răspuns la stimulii din 
partea actorilor. Acestea se reprezintă prin elipse. 

În cazul exemplului nostru cazurile in care se face apel la sistemul de rezervare 
sunt atunci când un pasager dorește să facă o rezervare sau atunci când acesta doreşte să 
anuleze o rezervare făcută anterior. O primă diagramă a cazurilor de utilizare este 

. reprezentată în figura 7.59. Într-o iterajie ulterioară această diagramă va putea fi rafinată, 
fiind identificate și alte cazuri de utilizare, cum ar fi confirmarea unui zbor, 

£ Fiecare caz de utilizare este documentat printr-o descriere a scenariului. 

- Descrierea poate fi textuală sau pe pași. În figura este prezentată si o descriere sub forma 
unei succesiuni de paşi pentru cazul de utilizare „Rezervare zbor”, Fiecare caz de 

-utilizare poate avea şi alte proprietăţi, cum ar fi pre- sau post- condiții ale scenariului — 
condiţii care trebuie îndeplinite înainte de inceperea execuţiei scenariului sau condiţii 
care trebuie îndeplinite după executarea scenariului. Diagrama de activitate reprezintă un 

- instiment grafic pentru modelarea proceselor cazurilor de utilizare. Aceasta va fi 
detaliată într-o secţiune ce urmează. 

i Obiectivul final al oricărui proiect software este o aplicaţie care răspunde tuturor 

cerinţelor beneficiarului. Prin identificarea şi verificarea cerinţelor se urmăreşte ca toate 

Cerinţele să fie luate în considerare şi sistemul să fie proiectat conform cerințelor 
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iniţiere a proiectului sau viziunea), iar cazurile de utilizare sunt folosite pentru a corela 
fiecare scenariu cu cerința pe care o tratează. Modelarea sistemului cu ajutorul cazurilor 
de utilizare ajută la identificarea cerințelor, dacă acestea nu au fost identificate anterior. 


L2 a 


A i 


d 
Fig. 7.59. Modelarea cu ajutorul cazurilor de utilizare 


7.13.4. Analiza orientatá obiect 


Principalele activităţi ce trebuiesc parcurse in această etapă sunt: : 

- Rafinarea diagramei cazurilor de utilizare; $ 

- Modelarea dinamicii sistemului (utilizând diagrama de secvenį diagrama 
de colaborare); ian 

= Modelarea structurii statice (utilizând diagrama claselor). 


Rafinarea diagramei cazurilor de utilizare 
„În această etapă se pot identifica si alte cazuri de utilizare si ali actori, la un alt 
nivel de detaliu. În exemplul nostru am identificat în plus agenţia de voiaj, ca intermediar 
între pasager si companie. Odată cu introducerea acestui nou actor am mai luat în calcul 
şi necesitatea achitării biletului pentru validarea rezervării si alte situaţii speciale care ar 
trebui acoperite (achitare prin carte de credit, plată neacceptată). De asemenea în cursul 
analizei proceselor de afaceri se poate dezvolta modelul al cazurilor de utilizare pentru 
Întreg sistemul şi se pot construi mai multe pachete pentru reprezentarea unor diverse arii 
ale afacerii. Fiecare pachet poate fi apoi descompus şi reprezentat printr-o diagramă ce 
conţine cazurile de utilizare corespunzătoare domeniului şi interacţiunile cu actorii. 
Scopul este de a construi câte o diagramă a cazurilor de utilizare pentru fiecare 
scenariu al sistemului. Fiecare scenariu descrie o succesiune diferită de interacțiuni între 
actori şi sistem, fără condiţii „SAU”, 
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Modelarea structurii alternative prin relaţii de tip , Extends" 

În mod obişnuit fiecare caz de utilizare se construieşte dintr-o secvență de acţiuni, 
după care pentru fiecare pas se construiesc condiţii de tip "what if" şi se realizează noi 
cazuri de utilizare pe baza acestor activităţi alternative. Secvenele alternative sunt 

inse în cazuri de utilizare distincte conectate printr-o relaţie de tip "Extends" de cazul 
de utilizare initial. Relaţia de tip "Extends" poate fi privită ca relaţie de moștenire întrucât 
cazul de utilizare ce extinde un alt caz de utilizare moşteneşte şi suprascrie 
comportamentul acestuia. Presupunând că achitarea biletului se face implicit prin 
numerar, dar opțional plata se poate face și prin carte de credit, cazul de utilizare 
„Achitare prin carte de credit” extinde cazul de utilizare „Achitare zbor” (figura 7.60.). 


Eliminarea comportamentului redundant cu ajutorul relațiilor de tip , Uses" 

Pentru a elimina o secvență de comportament redundant ce apare în cazuri de 
utilizare diferite se poate modela acea secvenţă într-un caz de utilizare distinct conectat 
de cazurile de utilizare iniţiale prin relaţii de tip „Uses”, Relaţia de tip "Uses" poate fi 
privită ca fiind echivalentă cu relaţia de agregare. În exemplul nostru, fie cà rezervarea se 
face direct la linia acriană sau printr-o agenție de voiaj, o rezervare trebuie achitată pentru 
a fi validată. Cazul de utilizare „achitare zbor” este utilizat atăt de „Rezervare zbor”, cât 
side „Rezervare zbor prin agent" (figura 7.60.). 


Q 


itare 
r Ls Plata neacceptata Agentie de Voiaj 


Fig. 7.60. Relaţii de extindere şi de utilizare între cazuri de utilizare 


Cazurile de utilizare sunt folosite și pentru a construi scripturi de testare pentru a 
verifica satisfacerea cerințelor beneficiarului, de către aplicaţie. Când se atinge nivelul cel 
mai fin de descompunere, pentru fiecare caz de utilizare se poate realiza o diagramă de 
secvenţă. Cu diagramele de secvenţă şi de colaborare se modelează implementarea 
scenariului. 


Modelarea dinamicii sistemului — Diagramele de secvență 
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Diagrama de secvenţă este una dintre cele mai ivite pentru a modela 
Bxscilnie bs e r Ga sialoterk clt a a Qo mio Pose 
fiecare caz de utilizare. În timp ce cazul de utilizare modelează un scenariu din puntul de 
vedere al utilizatorului, diagrama de secvenţă conține detalii de implementare ale 
scenariului, incluzând clasele și obiectele ce vor implementa scenariul şi mesajele 
transmise între obiecte. În mod obișnuit se analizează descrierea cazului de utilizare 
pentru a determina care sunt obiectele necesare pentru implementarea scenariului. Dacă 
descrierea a fost făcută sub forma unei succesiuni de paşi obiectele se determină prin 
parcurgerea acestor pași. Într-o diagramă de secvență obiectele implicate în scenariu sunt 
reprezentate prin linii punctate verticale, iar mesajele transmise între acestea prin vectori 
orizontali. Mesajele se reprezintă cronologic de sus în jos, spatierea pe orizontală a 
obiectelor fiind arbitrară. Pentru cazul de utilizare descris mai sus prin paşi („Rezervare 
zbor”) diagrama de secvenţă este prezentată în figura 7.61. Se observă că paşii din 
descrierea cazului de utilizare se regăsesc în secvenţă de sus în jos. 


axi 


Fig. 7.61. Diagrama de secvenţă pentru un scenariu 


În cursul analizei mesajul poartă denumirea din sistemul existent. Mai târziu, în 
cursul proiectării acesta este înlocuit cu denumirea metodei obiectului apelat. Metoda 
apelată sau invocată aparține clasei instanțiate de obiectul ce recepționează mesajul. 


Modelarea dinamicii sistemului — Diagramele de colaborare 

Diagrama de colaborare reprezintă o alternativă la diagrama de secvență pentru 
modelarea interacțiunilor între obiectele sistemului. În timp ce în diagrama de secvenţă 
accentul cade pe succesiunea cronologică a mesajelor, în diagrama de colaborare accentul 


250 


«rota N 


cade pe identificarea si înțelegerea tuturor efectelor pe care scenariul le are asupra unui 
obiect (figura 7.62). Obiectele sunt conectate, fiecare legătură fiind o instanță a asocierii 
între clasele implicate. Legătura evidenţiază mesajul transmis între obiecte, tipul 
mesajului (sincron, asincron, simplu, opțional -balking sau time-out) şi vizibilitatea 
obiectelor unele faţă de altele. 


Fig, 7.62. Diagrama de colaborare pentru un grup de obiecte 


Modelarea structurii statice cu ajutorul diagramei claselor 

Diagrama claselor este instrumentul principal de analiză și proiectare a structurii 
statice a sistemului. În ea se precizează structura claselor sistemului, relaţiile între clase şi 
structurile de moştenire. În timpul analizei diagrama este construită urmărind obţinerea 
unei soluții ideale. La proiectare se utilizează aceeasi diagramă şi se modifică pentru a fi 
conformă cu detaliile de implementare. 


Dezvoltarea diagramei claselor pe parcursul analizei 


Abordarea orientată pe cazuri de utilizare 

În cazul analizei orientată pe cazuri de utilizare, diagrama claselor se construieşte 
pe baza informaţiilor fumizate de cazurile de utilizare, diagramele de secvenţă și 
diagramele de colaborare. Obiectele identificate pe parcursul analizei sunt modelate în 
termenii claselor instanjiate de acestea, iar interacţiunile între obiecte sunt transpuse în 
relaţii între clasele instanfiate (figura 7.63). 


Abordarea orientată pe responsabilități 

Tehnica fişelor CRC este utilizată uneori ca extensie a UML-ului pentru o analiză 
orientată pe responsabilităţi. Definiţiile claselor sunt rafinate pe baza responsabilităţilor 
lor şi a altor clase cu care acestea colaborează pentru a îndeplini aceste responsabilităţi, 
Pentru fiecare clasă se întocmeşte o fişă pe care se evidenţiază responsabilităţile clasei şi 
care sunt clasele cu care ea colaborează pentru a îndeplini aceste responsabilităţi. Aceste 
informaţii se transpun direct într-o diagramă a claselor, responsabilitàtile corespund 
metodelor, iar colaborările corespund asocierilor dintre clase (figura 7.64.). 
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Fig. 7.63, Diagrama claselor în etapa de analiză 
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Fig. 7.64. O extensie informală a UML - tehnica fişelor CRC 
pentru analiza orientată pe responsabilităţi 


7.13.5. Proiectarea orientată obiect 


Există două obiective principale pe care le urmărim în proiectarea unui sistem 
informatie: 

- obținerea cât mai rapidă a sistemului care să respecte toate cerinţele actuale la un 

pret cât mai scăzut; 

- construirea unui sistem uşor de întreţinut si adaptat pentru a răspunde unor viitoare 

cerinţe. 

Aceste obiective sunt văzute în mod tradiţional ca fiind conflictuale; unul dintre 
motivele pentru care tehnicile de proiectare orientate obiect au cucerit cu rapiditate piața este 
şi concilierea acestor obiective conflictuale. 

Ca si în cazul analizei principalele activităţi ce trebuiesc parcurse în această etapă 
sunt: 

- Modelarea structurii statice (utilizând diagrama claselor); 

- Modelarea dinamicii sistemului (utilizând diagrama de stare sau diagrama de 

activitate); 

-  Rafinarea diagramei cazurilor de utilizare (utilizând diagrama de activitate); 

- Modelarea arhitecturii sistemului (utilizând diagrama componentelor si diagrama 

de 23 

- Proiectarea bazei de date. 

Accentul cade de această dată pe detaliile concrete ale implementării sistemului. 
Fiecare dintre modele abordate vin să completeze diagrama claselor / obiectelor care în final 
va sta şi la baza proiectării bazei de date. 

Proiectarea sistemului cu ajutorul diagramei claselor. Pe parcursul proiectării 
diagrama claselor este modificată pentru a lua în considerare detalii concrete ale 
implementării sistemului. Diagrama claselor poate fi dezvoltată într-o manieră iterativă, 
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printr-o succesiune repetată a analizei, proiectării şi implementării. Acest proces este adesea 
referit ca „round-trip engineering". Utilizarea unui CASE poate facilita acest proces oferind 
posibilitatea implementării într-un limbaj de programare cum ar fi C++ sau Java si invers, 
reactualizarea diagramei claselor pornind de la cod (reverse engineering). 


EE o 


EL 
Tum 


Fig. 7.65. Analiza şi proiectarea iterativă, documentarea 
cu ajutorul diagramei claselor 


O preocupare esenţială pe parcursul proiectării este stabilirea arhitecturii sistemului. 
Se poate opta între o aplicaţie simplă ce va rula pe o singură mașină, un sistem client-server 
sau un sistem multi-tier cu obiecte specializate pentru interfaţa cu utilizatorul, logica aplicaţiei 
şi pentru baza de date, fiecare putând potențial să ruleze pe o altă platformă. O posibilitate de 
a gestiona o astfel de arhitectură complexă este împărţirea diagramei claselor în trei secţiuni 
diferite care să evidenfieze clasele ce descriu interfaţa cu utilizatorul (business layer), clasele 
responsabile de logica aplicaţiei (application layer) şi clasele pentru stocarea datelor (data 
layer). Aceasta se poate realiza fizic fie prin segmentarea diagramei claselor şi utilizarea unci 
diagrame distincte pentru fiecare secțiune sau prin adăugarea unei proprietăți fiecărei clase, 
proprietate care să identifice cărei secțiuni (tier) aparține clasa. 

O componentă este un grup de obiecte sau componente care interacționează cu scopul 
de a furniza un serviciu. O componentă este similară unei cutii negre pentru care serviciile 
sunt specificate prin interfața sau interfețele sale, fără a se preciza nimic despre componenți 
sau implementarea internă a componentei. Dezvoltarea bazată pe componente este procesul 
care urmăreşte asamblarea componentelor celor mai potrivite în configurația cea mai bun 
pentru a obține funcţionalitatea dorită pentru sistem. Componentele sunt reprezentate în 
diagrama claselor din UML prin specificarea interfeţei clasei sau pachetului. Există dou! 
posibilități de reprezentare pentru interfaţă, ca o clasă cu stereotipul <<interface>> si list 
operaţiilor suportate de interfață în secţiunea destinată metodelor sau în variantă prescurtată: 
ca un mic cere atașat printr-o linie continuă de clasă si precizând denumirea interfeţei în 
dreptul cercului. 1 

Exemplul din figura 7.66. arată că interfața Afişabil a clasei Pasager pune la dispoziţie 
o operaţie mută(x coord, y coord) pentru afişarea în GUI. Sunt evidenţiate ambele modalit? 
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. Interfața Persistent a clasei Pasager oferă o operaţie salveazi(: 
fi folosită de o clasă sau componentă de acces la baza de date, MISIT 


de 


4 Fig. 7.66. Proiectarea componentelor — specificarea interfeței unei clase 

ie 

` Modelarea comportamentului cu diagrame de stare. În timp ce diagrame 
“interactiune si de colaborare modelează comportamentul dinamic reprezentat de a iai es 
„acțiuni între grupuri de obiecte ale sistemului, diagrama de stare este utilizată pentru a modela 
comportamentul dinamic al unui singur obiect sau clasă de obiecte. Se realizează câte o 
diagramă de stare pentru fiecare clasă cu comportament dinamic semnificativ. Într-o astfel de 
diagramă se surprinde secvenţa stărilor pe care le parcurge un obiect al clasei pe parcursul 
întregului său ciclu de viaţă ca răspuns la stimulii primiţi, dar si propriile răspunsuri şi acțiuni 
ale obiectului. Mai concret, comportamentul unui obiect este modelat pornind de la starea sa 
iniţială şi determinând care sunt stările pe care le tranzitează atunci când intervin diverse 
evenimente. Se urmăresc şi acţiunile pe care obiectul le efectuează atunci când se află într-o 
anumită stare. Stările reprezintă suma condiţiilor obiectului la un moment dat, Evenimentele, 
Sunt Întâmplări care determină trecerea unui obiect dintr-o stare în alta. Stările de tranziţie 
Caracterizează mișcarea dintr-o stare în alta. Fiecare stare de tranziţie (reprezentată printr-o 
M ce ER cele două stări între care se efectuează tranziţia) este etichetată cu 
evenimentul care determină tranziţia. Acţiunile i i 
riae csset ţi cţiunile sunt efectuate de obiect atunci când acesta 


Fig. 7.67. Modelarea comportamentului dinamic al obiectului Zbor 
cu ajutorul diagramei de stare 


Diagrame de activitate. Diagrama de activitate este o diagramă de flux utilizată pen 
e a tru 
la comportamentul sistemului. Ea poate fi folosită în mai multe situaţii: pentru a 
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modela un caz de utilizare, o clasă sau o metodă mai complicată. i 

notabile re la pat pr pă pa er epe plena componentele sistemului, grupate uneori în pachéte, i dependenele care exit 
poate reprezenta procese paralele. Acest lucru este deosebit de important atunci ise componente (i pachete de componente) (figura 7.692. " 
diagramele de activitate sunt utilizate pentru a modela procesele de afaceri (multe din ac "Modelarea distribuirii si implementării. Diagrama de desfășurare este utilizată pentru 


executându-se în paralel) sau pentru a modela fire multiple i ia configuraţia elementelor de procesare la momentul execuţiei si distributia 
concurentă. ja fire multiple de execuţie în progrmam | 3 "9% Jor software, proceselor gi obiectelor pe aceste elemente de procesare. Se pornește 
Utilizarea diagramelor de activitate pentru a modela cazuri de utili i . i identificarea nodurilor fizice si a comunicaţiilor ce există între acestea. Pentru fiecare 
deos ma Ead ctr tma nenea c dead d sod se precizează instanțele componentelor care se stochează sau se execută pe nodul 
poate fi folosită în completarea, sau în locul, unei descrieri textuale / liste de paşi a cazului de i. Se pot evidenția şi obiectele componentei respective. Diagrama de desfăşurare 
utili CO descien indios, d aseara a aat rpa doar componentele existente la momentul execuției, ca nu surprinde si 
detali " componentele folosite doar la compilare sau linkeditare. Se pot E e is pupe 
izarea diagramelor de activitate pentru a modela clase. Pe - | migrează dintr-un nod în altul, sau obiectele ce migrează intr-o componentă într 
PE, efon E go cce punerea viget relația de dependență cu stereotipul «becomes» (figura 7.70). 
evenimentele asincrone. Diagrama de activitate se reao când toate sau majoritatea 
sunt urmare a unor acţiuni interne. astfe diagramă activităţie 
trebuiesc atașate claselor (figura 7.68.). i9 antc — 


Pasager Valzater 


c—— 


a cu ajutorul diagramei 


Verifica disponibilitatea 


Fig. 7.69. Modelarea componente 
componentelor 


EXE TY PRE 0 văl 


Furmizeaza optiuni si preturi i I Ford 
|- po LAN —] 


1 


7.10. Modelarea distribuirii sistemului cu ajutorul diagramei de desfăşurare 


Fig. 


Fig. 7.68. Diagrama di 


„Modelarea componentel. fiware. Diagrama componen n i Proiectarea bazelor de date relafionale — o extensie UML 
modus near aia su Inna dependen Jur componente ] Dinga uim pez un recie ret rime aite aso P 
PN i cutabile. În diagrama componentelor Telaile diste ele pot fi implementate direct într-o bază de date orientată obiect. Cu toate 
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persistente si atributelor acestora le corespund entităţile logice si atrib price 
dintre clase le corespund relații între eatităţi (figura 7.71). si atributele lor, iar relațiilor 


E 
81. Modelul obiectual-relațional 


Având în vedere faptul că atât modelul relational cát şi modelul obiectual al bazelor de 
- date prezintă avantaje şi dezavantaje, în jurul anilor 1990 s-a conturat pentru prima dată ideea 
de a reuni avantajele celor două modele, prin extensia modelului relafional cu caracteristici 
ale modelului obiectual şi crearea unui hibrid de model obiectual-relaţional. După lungi 
dezbateri, în 1999 grupul de lucru SQL a finalizat şi adoptat un subset a modelului de date 
obiectual-relațional. În 2003 grupul de lucru SQL a oferit suport deplin pentru submodelul 
obiectual-relațional cunoscut sub denumirea de SQL-3. 
- Corespunzător acestui model, o bază de date obiectual-relafionalà constituie un set de 
clase de nivel înalt, care sunt populate de obiecte tuplu [40,21]. 

Un obiect tuplu este de forma «oid, val», unde «oid» este identificatorul unui obiect, 

ier «val» este o valoare tuplu a cărei componente pot fi valori arbitrare, de genul: valori 
primitive, seturi, tupluri şi referinţe către alte obiecte. 
* Analizând cele două modele, obiectual-relational şi CODM, se poate constata că 
principala diferență dintre ele constă în faptul că pentru cel dintâi structura de nivel înalt a 
fiecărei instanțe obiect este întotdeauna un tuplu, că acele clase sunt numite relaţii, de unde 
deducem și termenul de "obiectual relational". 

În cel de al doilea model, structura de nivel înalt poate fi o valoare arbitrară, 
Comparând modelele obiectual-relafional şi relational tradiţional se poate deduce faptul că, 
modelul relațional poate fi privit ca un subset al modelului obiectual-relajional şi, deci, 
implicita CODM. 


" y i 
Fig. 771. Proiectarea bazelor de date relaionale cu ajutorul diagramei entitate 
asociere 


Odată întocmită această diagramă sc i 
sa | ac diagr: poale trece la proiectarea bazei de date 
relationale conform tehnicii normalizării (prezentată într-un alt capitol). s 


8.2. Modelul SQL3 — standard pentru BDOR 


Modelul SQL3 constituie un alt standard de mare referinţă în materie de gestiunea 
datelor obiectual-relationale. 


Preocupări a constituit-o tocmai faptul că trăsătura principală a unui model obiectual, 
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Prima versiune a standardului SQL a fost numită SQL86. Ea era bazată în mare 
pe Limbajul SEQUEL, limbaj făcând parte din proiectul System R al firmei IBM. O versi 
revizuită a lui SQL86 a fost publicată în 1989, versiune ce adaugă si tratează integri 
referentialà. În 1992 a fost publicată o altă versiune, sub denumirea de SQL92, ce aduce 
caracteristici, cum ar fi: integritatea, domeniile, tabele temporare, noi tipuri de operaţii 
joncțiune, actualizarea schemelor bazelor de date, cu facilități pentru cursor privind navigarea 
în rezultatul unei cereri etc. În acest mod, SQLS2 a ajuns a fi considerat limbajul standard 
pentru baze de date relaționale. Ulterior, printr-o serie de extensii relevante privind modelare 
obiectuală s-a ajuns la SQL3 (SQL3 2003), considerat a fi standardul pentru baze de date | 
obiectual-relafionale. Hi 
În cele ce urmează modelul de date utilizat de sistemele de gestiune a bazelor de date _ 
obiectual-relaționale (SGBDOR) va fi numit „modelul de date SQL3", deoarece este definit 
prin limbajul de definire a lui SQL-3. El este compatibil cu modelul de date relational, definit 
în SQL-2. Astfel, în modelul SQL-3 este posibil să definim tabele SQL-2, cum ar fi tabela 
PERSOANA, cu constrângerile de integritate ale lui SQL-2: 1 


i 


wti 


CREATE TABLE persoana( 
marca INTEGER. primary key. 
nume CHARGO), 
prenume  CHARGO), 
cnp INTEGER. 
data-nasterii. DATE, E 
localitatea  CHAR(25)); 4 


Totuşi, abordarea sugerată în modelul obiectual-relaţional înseamnă mai întâi să se 
definească un tip pentru tupluri, care apoi să-l facă reutilizabil. Gi 
In definirea oricărui tip este posibil să folosim constructorii de tip complex, care în - 
mod semnificativ extind noţiunea de domeniu prezentă in SQL-2. Disponibilitatea 
constructorilor de tip este prima mare diferență faţă de bazele de date relaţiomale clasice. = 
Cele mai semnificative caracteristici cu care a venit SQL3, ca suport pentru structurile $ 
orientate obiect sunt: U 
- tipuri definite de utilizatori, regăsite anterior sub denumirea de tipuri de date 
abstracte; 1 
tipuri rând; 
tipuri referință; 
constructori pentru tipuri de rând şi tipuri de referinţă; 
constructori de tip pentru tipuri de colecţii (seturi, liste şi multiliste); 
funcţii şi proceduri definite de utilizator; 
suport pentru obiecte mari (BLOB-uri şi CLOB-uri); 
valoarea de pe nivelul cel mai înalt a fiecărui obiect, în SQL3, este un tuplu. 
Tuplurile şi seturile pot fi imbricate. 3 


Prin toate aceste caracteristici s-a urmărit ca SQL3 să devină, pe de odel 
dere t SQ! devină, pe de o parte, un me 
tradițional relational, iar pe de altă parte, să dispună de capacități puternice procedurale în 
ideea de a-i conferi completitudinea de programare, asemănător altor limbaje de programare... 


Bazele de date obiect-relaționale-Standardu! SQL3 
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82.1. Noi tipuri de date in SQL3 


Comparativ cu versiunile precedente, SQL3 oferă posibilitatea utilizării unor noi tipuri 
date, pe care le vom prezenta în cele ce urmează: 

D. Tipuri rând (tuplu). Un tip rând reprezintă o secvență de perechi de denumire de câmp 
și tip de data asemănător definirii unei tabele. Două rânduri sunt tipuri echivalente dacă 
Sxindoul au același număr de câmpuri şi fiecare pereche de câmpuri de pe aceiași poziție au 
tipurile compatibile. Tipul rând furnizează un tip de dată ce poate reprezenta tipuri de rânduri 
într-o tabelă, astfel că acestea pot fi stocate în variabile, trecute ca argumente în rutine şi 
metumând astfel valori dintr-o funcţie invocată. Această facilitate, de asemenea, permite 
coloanelor dintr-o tabelă să conţină valori rând. De exemplu: 


CREATE TABLE persoana( 
CNP INTEGER, 
Nume CHAR (30), 
Adresa ROW (localitate CHAR (25), 
Strada CHAR (25), 
Blocul ROW(n  CHAR(4), 
seara CHAR Q), 
etaj INTEGER 
apart INTEGER))); 
INSERT INTO persoana 


VALUES (1950126400237, 'VASILE' , ("Bucuregti', 'Romana', ('11', ‘A2’. 1, 79))); 


În definirea tabelei PERSOANA, constatăm prezența a două atribute adresa $i blocul 
care sunt de tip ROW şi astfel ele pot lua valori rând. 


Tipuri de obiecte mari — BLOB şi CLOB. Tipurile de obiecte mari (Large Object- 
LOB) pot fi grupate în BLOB-uri și CLOB-uri. Tipurile BLOB (Binary Large Object) și 
CLOB (Character Large Object) au fost definite ca suport pentru obiecte foarte mari. 
Instanjele acestor tipuri sunt memorate direct în baza de date, mai degrabă decât existând 
menţionate în fişiere externe. De exemplu: 


CREATE TABLE persoana 
CNP INTEGER, 
nume VARCHAR (25), 

VARCHAR (15), 


salariu INTEGER, 


poza BLOB (15M); 


Tipurile LOB nu acceptă anumite operaţii cum ar fi "mai mare decâr” sau "mai mic 
decât”, însă suportă alte operaţii cum ar fi cea de regăsire, predicatul LIKE ete. Totodată, ele 
pot suporta o serie de operaţii specifice obiectului. Exemplu, pentru o poză: măreşte, 
micşorează sau roteşte poza. 

Tipuri de date abstracte (TDA) în SOLS. Reamintim faptul că în CODM un tip 
teprezintă un set de reguli pentru structurarea datelor. Setul de obiecte ce se conformează 


E 


acelor reguli reprezintă domeniul tipului. În acest context, precizăm faptul că una din ideile de 
bază care se află în spatele posibilităţilor obiect aduse de SQL3 este aceea că pe lângă tipurile 
normale, cum ar fi INT, CHAR, FLOAT etc., construite înăuntru definirilor în SQL, pot fi 
precizate si construite TDA. dc 

Tipurile de date abstracte (Abstract Data Type-ADT) in SQL3 sunt numite tipuri 
Definite de Utilizator - TDU. A 

Crearea unui astfel de tip separat de un tabel, deşi folosind o sintaxă aproape identică 
cu cea pentru crearea unui tabel, apare astfel: 


CREATE TYPE Adresa ( 
localitatea CHAR (20), 
strada CHAR (20), 
numar INTEGER, 
bloc CHAR (3), 
apartament INTEGER); 


O utilizare a unui astfel de tip poate fi ca un tip de dată coloană în cadrul unei tabele, 
astfel: 


CREATE TABLE persoana ( 
CNP CHAR (13), 
nume CHAR (15), 
prenume — CHAR (15) : 
adresa Adresa, 


profesia — CHAR (20); 


Tabela PERSOANA este primul nostru exemplu nonrelational, ea având inclus un 
atribut adresa de „tip compus”, după oricare regulă rezonabilă de compoziţie. 

În acest mod utilizatorii au posibilitatea de a-și defini noi tipuri de date în mod 
arbitrar, a le stoca şi regăsi exact ca pe un obiect de alt tip, cum ar fi "integer". Mai mult, 
pentru astfel de tipuri de date se pot defini de către utilizatorul care le-a creat şi operaţii 
specifice. De exemplu, asupra tipului de date imagini s-ar putea defini operaţii ca: roteşte 
imaginea, decupează, măreşte rezoluția, comprimà imaginea etc. 

Un tip de date abstract definit de utilizator, precizează atribute si operaţii încapsulate 
într-o singură entitate. La modul general, un TDA este analog cu definirea unei clase într-un 
limbaj de programare orientat obiect, el specificând un ansamblu de definiţii de atribute $ 
declaraţii de rutine. Toate instanțele unui TDA partajează atributele şi rutinele acestuia. 

Aceste tipuri de date sunt etichetate "abstracte" pentru că sistemul de bază de date nu 
are nevoie să ştie cum se stochează datele TDA şi nici cum funcționează metodele TDA. El 
trebuie să ştie doar ce metode sunt disponibile şi tipurile de date de intrare/ieșire pentru acele 
metode, 

În SQL3 atributele sunt considerate atribute stocate, respectiv, virtuale. Atributele 
stocate reprezintă cazul general de atribute utilizate în multitudinea limbajelor de programare 
sub denumirea de câmpuri. Atributele virtuale, în alte limbaje de programare le regăsim sub 
denumirea de atribute derivate. 

Totodată în SQL3 rutinele definite de utilizator (RDU) au semnificaţia de metode, aș: 
după cum vom vedea şi în paragrafele următoare. Acum este uşor să vedem cum se post 
extinde SQL, ca sistem relafional, cu noi tipuri si trăsături necesare pentru ca el să fie calificat 
ca un sistem obiect: 

CREATE TYPE Persoanatip AS ( 


262 


- PRIVATE 
13 data-naşterii DATE CHECK | (data-nagterii «DATE '2007-08-01 pă 
PUBLIC 
CNP INTEGER, 
prenume CHAR (15), 
E nume CHAR (13), 
Lai adresa Adresa); 
5 
+ CREATE TYPE Angajattip UNDER Persoanatip AS ( 
E marca INTEGER, 


PRIVATE 
É salariu INTEGER, 
i comision INTEGER, 
| PUBLIC 
: studii CHAR (15), 
sex CHAR (1), 

MEMBER FUNCTION câştig RETURN integer) 


CREATE TYPE BODY Angajattip AS 
MEMBER FUNCTION câştig RETURN integer IS 
BEGIN 
RETURN salariu + comision; 
END; 


Exemplu anterior arată modul de creare a unui subtip ANGAJATTIP al supertipului 
PERSOANATIP, recurgându-se la proprietatea de moştenire evidenţiată prin clauza UNDER 
(Angajattip UNDER Persoanatip). pen astfel de situaţie, subtipul ANGAJATTIP, pe lângă 
proprietăţile şi metodele sale, include şi atributele moștenite de la supertipul PERSOANATIP, 
Deci, de reținut faptul că o instanță a unui subtip este considerată ca o instanță a tuturor 
supertipurilor sale. 
Limbajul SQL3 acceptă conceptul de substitufionalitate adică ori de câte ori este de 
aşteptat o instanţă a supertipului în locul acestuia poate fi utilizată o instanță a subtipului. 

Prima instrucţiune CREATE TYPE din punct de vedere sintactic este similară cu 
definirea unei tabele în concepția relaţională (CREATE TABLE persoana). Deosebirea constă 
în faptul că acum noi definim un alt tip decât o tabelă, tip ce confine definiri proprii ale 
utilizatorului (exemplu tipul Adresa). 

Comanda a doua este mult mai interesantă. Ea defineşte 
Supertipului Persoanatip, ceea ce este specificat prin clauza UNDER. 
În ambele cazuri se ilustrează utilizarea unor atribute publice şi private. Atributele 
naşterii, salariu şi comision sunt private. Atributele private sunt utilizabile doar prin 
iul unor rutine/metode imbricate în definirea TDA-ului. În mod implicit, vizibilitatea 
Mui atribut public sau privat este aceea a atributului imediat precedent. 

Primul atribut a unui TDA, dacă nu prevede specificarea vizibilităţii, în mod implicit 
este public. 

Totodată exemplul evidenţiază folosirea de atribute înregistrate/stocate şi atribute 
Ytuale/derivate. Un atribu/înregistra este cazul implicit, cu o denumire şi un tip de date. 

Pul de date poate fi orice tip de date cunoscut, inclusiv alte tipuri definite de utilizator. 
Atibutul Câştig este declarat cu ajutorul funcţiei ce comportă o aceiași denumire. 


un subtip Angajattip al 


Capitolul 8 


Definirea tipului ANGAJAT include si definirea unei metode tip funeţie cu denumirea 
Câştig, prin intermediul căreia sunt accesate două atribute private Salariul şi respecti. 
Comision. 

Referitor la TDU (în contextul SQL3) ținem să facem următoarele precizări: i 

a) tipurile definite de utilizatori îşi justifică utilitatea doar dacă sunt incluse sau asociate - 
unor tabele, în care urmează a fi stocate şi obiectele; 

b) tipurile definite de utilizatori sunt necesare în următoarele două principale situaţii şi 
anume: 

b1) Pentru a specifica cazuri particulare ale domeniilor unor atribute dintr-o tabelă, 
tocmai ca şi tipurile primitive de întregi sau şiruri de caractere, astfel: 


CREATE TABLE LICENTIATIC 
Licenţiat REF (Angajattip), 
Universitatea CHAR (20), 
Facultatea CHAR (25). 
Localitatea CHAR (20); 


Se poate observa că sintaxa instrucţiunii CREATE TABLE este similară cu sintaxa 
creării unei tabele obișnuite, cu unica deosebire că în definirea atributului Licenţiat se 
specifică domeniul ca fiind un tip complex (ANGAJATTIP). Tipul REF (Angajattip) 
precizează faptul că valoarea asociată atributului Licenţiat trebuie să fie un OID a unui obiect 
de tip ANGAJATTIP. Detalii despre tipul referinţă (REF) se regăsesc în capitolul următor. 

b2) Un TDU poate fi folosit pentru a specifica tipul unei tabele complete. Acest lucru 

se realizează tot cu ajutorul instrucţiunii CREATE TABLE însă într-un alt mod. În acest 
caz, în loc de enumerarea- coloanelor/atributelor unei tabele se recurge la simpla 
precizare/citare a TDU. Aceasta înseamnă că toate tuplurile tabelei trebuie să aibă 
structura specificată de TDU. E 
Exemplu 1. Putem crea o următoare tabelă bazată pe o definire prealabilă, astfel: n 
i 


CREATE ANGAJAT OF ANGAJATTIP; 


În acest mod a fost creată tabela ANGAJAT plecând de la un TDU numit, 
ANGAJATTIP. Tabelele construite „via CREATE TABLE ... OF ... sunt numite tabele tip”. 
Rândurile unei tabele tip sunt considerate a fi obiecte. Š 


Exemplu 2. Considerăm tabela PERSOANA creată anterior. In actualul context, E i 
poate fi descompusă în două definiri, de forma: * 


CREATE ROW TYPE persoanatip( 
Marca INTEGER primary key, 
Nume CHAR(30), 
Prenume CHAR(30), 
Cnp INTEGER, 


Data-nasterii DATE, 
Localitatea  CHAR(25)); 


CREATE TABLE persoana of type persoanatip; 
Intr-o astfel de situaţie, tipul PERSOANATIP poate de asemenea fi utilizat şi 
definirea altor tabele, cum ar fi: 
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CREATE TABLE student of type persoanatip; 

CREATE TABLE profesor of type persoanatip; 

Observăm că obiectelor si claselor din modelul orientat obiect le corespund tupluri si 
tabele în modelul obiectual-rclafional. 

De remarcat faptul că în legătură cu metodele sau aşa numitele rutine definite de 
utilizator (UDR) există o adevărată filozofie sub aspectele elaborării lor în diferite limbaje de 
programare sau în legătură cu clasificarea acestora. Toate acestea comportă anumite 
particularități în funcţie de limbajul de programare folosit, versiunile acestuia sau în funcție 
de sistemul de gestiune a bazei de date obiectual-relațională (SGBDOR) care le 
implementează. Ca o cerinţă, un SGBDOR trebuie să ofere o flexibilitate sporită în ceea ce 
priveşte permisiunea ca rutinele UDR sa returneze valori complexe, care să poată fi 
manipulate mai departe, cum ar fi tabelele. Totodată, un SGBDOR trebuie să ofere suportul 
pentru supraincárcarea denumirilor funcțiilor cu scopul de a simplifica dezvoltarea de 
aplicaţii. 

În SQL metodele pot fi de tip procedură sau funcție, ca si în alte limbaje de 
programare. Ele la rândul lor pot fi clasificate ca metode constructor, de ştergere sau de 
manipulare (denumirea acestora sugerează şi scopul fiecăreia). Metodele pot fi definite 
complet în limbajul SQL sau într-un alt limbaj de programare standard, cum ar fi C/C++, În 
situația în care definirea metodelor se realizează in SQL , codul metodei va fi încadrat într-un 
bloc „BEGIN ............ END" iar în final va fi stocat împreună cu schema bazei de date în 
dicţionarul bazei de date. Dacă corpul metodei este scris în limbajul C se va recurge la 
specificarea unei clauze externe care va identifica „codul compilat” stocat într-un fişier al 
sistemului de operare. De exemplu, dacă am dori să efectuám o prelucrare a "pozei" 
persoanelor stocate în baza de date şi cunoscând faptul că limbajul SQL nu poate realiza acest 
lucru am fi nevoiţi să utilizăm o metodă furnizată din exterior, de forma: 


METHOD poza () RETURN BOOLEAN 
CREATE METHOD poza () FOR persoana 
LANGUAGE C 

EXTERNAL NAME ‘file: /home/admin/poza'; 


Într-o astfel de situaţie, definirea tipului persoana include doar semnătura metodei nu 
şi corpul acesteia. Actuala definire este dată folosind instrucţiunea CREATE METHOD, care 
este asociată cu tipul persoana prin clauza FOR. Instrucţiunea precizează faptul că metoda 
este scrisă în limbajul C şi totodată indică mecanismelor SGBD legătura cu acea metodă şi 
unde poate fi găsită spre a fi lansată în execuţie, 

Limbajul SQL3 oferă aceleași operaţii ca şi SQL2 pentru integrarea si actualizarea 
tabelelor însă vine şi cu anumite extensii pentru manipularea obiectelor, cum ar fi cele 
referitoare la invocarea unor metode definite de utilizatori. 


Exemplu 1. Se cere să se listeze numele, prenumele şi câştigul angajaţilor care au 
studii superioare: 

SELECT A. nume, A. prenume, A. câştig 

FROM angajat A 

WHERE A. studii = "superioare '; 
în cadrul cererii se observă că este invocată şi funcția Cáytig definită de utilizator. 


Exemplul ., Se cere să se listeze marca, numele şi prenumele tuturor angajaţilor ce au 
un câştig mai mare de 2000 euro: 


SELECT A marca, A.nume, 4.premame 
FROM angajat A 
WHERE A.câștig > 2000; 


In acest caz metoda Câştig este invocată in construcția unui filtru (A.cástig > 2000), 
pe când în primul exemplu metoda cra invocată în cadrul "listei finta a Bazu SELECT. 
Metodele in cadrul unui tip pot fi definite încă din faza de proiectare a bazei de date 


sau pot fi adăugate în timp. În cele ce urmează vom ilustra modul în care adăugată 
nouă metodi la tipul ANGAJATTI?. la primul rând este necesară adăuga unei decai 
astfel: 


ALTER TYPE Angajattip 

ADD METHOD constructorangajat 
data-nasterii DATE, £ 
CNP INTEGER, 
marca INTEGER, 
prenume CHAR (15), 
nume CHAR (15), 
localitatea — CHAR (20), 
strada CHAR (20), 
numar INTEGER, 
bloc CHAR (3), 
apartament INTEGER, 
salariu INTEGER, 
comision INTEGER, 
studii CHAR (15), 
sex CHAR (1), 

RETURN Angajattip; 


Urmează să definim corpul metodei, astfel: 


CREATE METHOD constructorangajat. 
dara-nasterii DATE, f 


CNP INTEGER, 
marca INTEGER, 
prenume CHAR (15), 
nume CHAR (15), 
localitatea — CHAR (20), 
strada CHAR (20), 
numar NTEGER, 
bloc CHAR (3), 
apartament INTEGER, 
salariu INTEGER, 
comision INTEGER, 
studii CHAR (15), 

boss CHAR (1), 

RETURN angajattip 

LANGUAGE SQL 


BEGIN 
RETURN NEW angajattip () 
data-nasterii (data-nasterii), 
CNP (CNP), 
marca (marca), 
prenume (prenume), 
mume (nume), 
localitatea (localitatea), 
strada (Strada), 
numar (numar), 
bloc (bloc), 
apartament (apartament), 
salariu (salariu), 
comision (comision), 
studii (studii), 
sex (sex), 
END; 
Pe lângă cele precizate, o serie de alte detalii, pot fi găsite în capitolul următor cu 
privire la implementarea SQL3 în ORACLE. 
Din cele prezentate se poate desprinde concluzia că, actualmente avem de a face cu 


trei mari categorii de SGBD-uri şi anume SGBDR, SGBDOO şi SGBDOR. 
Compararea celor trei tipuri de SGBD-uri apreciem că este necesară și bine venită, 
motiv pentru care in cele ce urmează vom recurge la acest lucru. 


8.3. Compararea SGBDR cu SGBDOR 


'omparând SGBDR cu SGBDOR pot fi desprinse următoarele aspecte: 

* Un SGBDOR este un SGBD relațional cu extensiile SQL3; 

-~ Extensiile SQL3, includ: tipuri rând, tipuri definite de utilizator, rutine definite de 
utilizator, polimorfismul, moştenirea, referințe, identitatea obiectului, tipuri 
colecții (set, liste, ARRAY), noi construcții de limbaj ce fac SQL3 complet 
relational, triggers si suport pentru obiecte mari — Binary Large Objects (BLOBs) 
şi Character Large Objects (CLOBs). In acest mod putem construi tipuri de date 
mult mai complexe plecând de la tipuri atomice si tipuri definite de utilizatori 
utilizând constructori de tip. Există constructori de tip şi operatori corespunzători 
tuturor tipurilor de date. 

- Prin multitudinea tipurilor de date precum şi posibilitatea implementării 
proprietăţii de moştenire, SGBDOR ne oferă facilităţi privind proiectarea unei 
structuri de bază de date mai apropiată de starea naturală a lucrurilor şi totodată 
mai eficientă; 

- Un SGBDR se caracterizează printr-o simplitate si stabilitate sporită faţă de un 

SGBDOR, ceea ce îi conferă o mai mare uşurinţă de folosire; 

SGBDR tradiţional foloseşte indexurile de tip arbore-B”, pentru a accelera accesul 

la date; 

Ambele SGBD se caracterizează printr-o simplitate de dezvoltare datorită faptului 

că asigură independența datelor faţă de programare (aplicaţii); 
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- Pentru SGBDR există standardul Sí 


standardul SQL3; 


-  SGBDR apar ca produse software 


software încă în formare/perfecționare; 


-În ceea ce priveşte suportul 


moștenire, ceea ce duce impl 


8.4. Compararea SGBDOO cu SGBDOR 


* SOBDOO si SGBDOR suportă tipuri de date abstracte (in SQL tipuri definite de 


- SGBDOR încearcă să adauge trăsături ale SGBDOO unui SGBDR, iar SGBDOO 


la rândul lor au dezvoltat 
relafionale; 


e pentru programare, în cazul limbajelor de programare 
aparținând SGBDOR apare posibilitatea reutilizării codului, da ză 


licit la reducerea efortului de 


a SQL, iar SGBDOO suportă limbajele ODL si OQL; 


limbaje de cereri bazate pe limbajele de cereri 


* Atât SGBDOO cât şi SGBDOR asigură sistemelor de gesti 
SGBI gestiune a bazelor di 
funcționalitatea de control a concurenței de acces precum si de regisire a peter 


~ Diferența fundamentală între 
încearcă să-și îmbogăţească 


să adauge tipuri mai bogate de date unui SGBD relational 

= Fariliuţile de cereri ale OQL nu au suport eficient în majoritatea SGBDOO, în 
timp ce facilităţile de cereri sunt piesa centrală a SGBDOR. ^ 

~ Un SGBDOR este indicat pentru aplicaii ce implică colecții mari de date, obiecte 


ce pot avea structuri complex: 


SGBDOO şi SGBDOR constă în faptul că SGBDOO 
limbajele de programare pe când SGBDOR încearcă 


e/bogate si relativ mari; 
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QL2 (ANSI X3H2), iar pentru SGBDOR exisa 


foarte mature, pe când SGBDOR sunt produse 


lui, datorită proprietății de 
programare; 
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Capitolul 9 
Oracle-SGBD obiectual-relational 


SGBD-ul Oracle este un SGBD obiectual-relajional ce implementează modelul 
orientat obiect ca o extensie a modelului relafional. Se pot implementa conceptele de bază ale 
modelului orientat obiect şi anume: 

- conceptul de clasă de obiecte; 

- conceptul de moştenire simplă nu și multiplă; 

- toate tipurile de asocieri între clase; 

- conceptul de agregare, 


9.1. Tipuri de obiecte (Object types ) 


Tipul este identic cu o clasă din Java sau C++ şi reprezintă un set de obiecte cu 
structură (atribute) şi comportament similar. Metodele (proceduri şi funcții PL/SQL definite la 
momentul definirii tipului) sunt opționale pentru un tip si definesc comportamentul obiectelor 
de acest tip. Instanța unui tip se numeşte obiect . 

Pentru a crea un tip se utilizează comanda Creare Type. Definirea unui tip nu alocă 
spaţiu de stocare pentru acest tip. De exemplu, se va crea tipul Persoana t caracterizat prin 
atributele CNP, nume, prenume si telefon şi prin două metode: funcţia reurneaza_cnp() si 
procedura afiseaza detalii. Se va utiliza instrumentul SQL Developer (figura 9.1, figura 9.2). 

Un tip poate fi utilizat pentru a defini un atribut al unci tabele sau o variabilă de acest 
tip. De exemplu, tabela Curs are atributul profesor de tip persoana t. In acest caz, obiectele 
tipului persoana 1 se numesc obiecte coloană : 


create table curs 
(curs id varchar2(10), curs denumire varchar2(20), profesor student persoana, 1) 


Pentru a adăuga un tuplu în tabela Curs se utilizează comanda: 


insert into curs values 
(BD', 'Baze de date! persoana_1(2610925400129, 'Muntean', 'Mihaela', 3440652?) 


Metodele sunt funcţii sau proceduri ce pot fi declarate la momentul definirii tipului 
Pentru a implementa comportamentul. 


ax 
BAES OUTIS, PET AINE (TO SIEEN 2 ++ 
'2UNS. CUTYT. NUT, LIRE (eaa 
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Metodele pot fi scrise în PL/SQL sau în orice limbaj de programare. Metodele scrise 
PL/SQL sau Java sunt stocate în baza de date, iar cele scrise în alte limbaje cum ar fi C sunt 


stocate extern. 

Metodele permit accesul la datele unui obiect. De exemplu, comanda SELECT poate 
utiliza metoda returnează CNP() a tipului persoana_t pentru a afişa CNP-ul profesorilor din 
tabela Curs: 


Select c.profesor.returneaza_CNP() from curs c 


Metodele pot fi: membru, pentru comparare de obiecte (metode de mapare și de 
ordonare), statice, constructor. 

Metodele membru permit unci aplicaţii să acceseze datele unui obiect. Se defineşte o 
metodă membru pentru fiecare operaţie pe care dorim s-o executăm pe obiectele tipului 
“respectiv. De exemplu metoda volum() calculează volumul unui obiect de tip cub_1 f (ensi 
pe atributul /atura) si este o metodă membru. Aceste metode au un parametru predefinit SE) 
ESSE oon pep oco muda exe cre getea made br 
tip cub f cu trei metode: o funcţie suprafata(), o funcţie volum() şi o procedură afişează. 
- Metodele sunt scrise in PL/SQL: 


create type cub 1 as object ( latura integer, member function suprafata return integer, 
member function volum return integer, member procedure afiseaza (self in out nocopy cub 1)) 


Pentru fiecare metodă se specifică codul PL/SQL : 


create type body cub. t as 
member function volum return integer is 


return latura* latura * latura; 

end; 

member function suprafata return integer is 
begin 


return 6 * (latura * latura); 


Se utilizează pachetul dbms output pentru a afişa latura, volumul şi suprafaţa unui 
obiect de tip cub. 1: 


member procedure afiseaza (self in out nocopy cub, 1) is 


C dins. ! output.put line('latura cubului este : ' || ned 

-.dbms output.put, line('volumul cubului este : 
[eral ! output.put, line('suprafata cubului este : Drs ETUR 
“end; 


E Se creează o tabelă cuburi în care se vor stoca obiecte de tip cub t (de exemplu cubul 
B 10). Metoda volum() poate fi apelată într-o comanda SELECT (figura 9.3): 

Greate table cuburi (id number, cub cub 1) 
into cuburi values(1, cub 1(10)) 


pu 


Pentru tabela cuburi se specifică alias-ul c. In apelul metodei se specifică ali 
tabelei, denumirea coloanei care va stoca obiectele de tip cub f şi denumirea metodei: 


select c.cub.volum() from cuburi c 


Fig. 9.3. Apelul unei metode în comanda SELECT 
Procedura afiseaza poate fi apelată într-un bloc PL/SQL (figura 9.4): 


declare 

~- se defineşte o variabilă v care va stoca obiecte de tip cub. t 
vcub t; 

begin 

select c.cub into v from cuburi c where c.id=1; 

— denumirea metodei este precedată de denumirea variabilei 


tode pentru comparare de obiecte. Două obiecte pot fi comparate dacă sunt, 

act at aaa rper eta DEN tom tot aci el 

„Metoda de mapare este o funcţie membru fără parametri ce permite com) 

obiectelor unui anumit tip prin maparea lor la unul din tipurile de date: date, number, 
şi apoi ordonarea lor în funcţie de poziţia lor pe axă. 


Pes 
Fig. 9.4. Apelul unei metode 


Următorul exemplu defineşte o metodă de mapare aria() ce permite compararea 
obiectelor de tip dreptunghi în funcţie de aria lor : 


Create type dreptunghi_r as object (lungime number, latime number, 
map member function aria return number) 


Create type body dreptunghi t as 

Map member function aria return number is 
Begin 

Return lungime*latime; 

End; 


End; 


Metoda de ordonare permite compararea directă a obiectelor (specifică dacă obiectul 
curent este mai mic, egal sau mai mare decât alt obiect cu care este comparat, pe baza unui 
criteriu de comparare utilizat de metodă). Este de fapt o funcţie cu un parametru declarat 
pentru un alt obiect de acelaşi tip cu obiectul curent şi care returnează un număr negativ, zero 
sau un număr pozitiv. O metodă de ordonare este mai puţin eficientă, deoarece ea poate 
compara numai două obiecte la un moment dat, spre deosebire de metoda de mapare care 
poate compara mai multe obiecte la un moment dat. 

Un tip are cel mult o metodă de mapare sau o metodă de ordonare. Intr-o ierarhie de 
moştenire numai supertipul poate avea o metodă de ordonare. Dacă supertipul are o metodă de 
mapare, orice subtip poate avea o metodă de mapare care poate înlocui metoda de mapare a 
supertipului. 


.. Metode statice. O metodă statică nu are parametru SELF. Metodele statice pot fi 
utilizate pentru a defini constructori. 


m 


Metode constructor. O metodă constructor este o funcţie ce retumează o nouă i 
a tipului şi setează starea acestei instanțe. Fiecare tip are o metodă constructor definită în mod 
implicit de sistem. De exemplu, se consideră tipul persoana t (figura 9.1). Metoda 
constructor a acestui tip are aceeași denumire cu tipul. Pentru a crea un obiect de tip 
persoana t se apelează această metodă: persoana 1(2134913456411, ‘Ionescu’, ‘Doina’, 
3440244). Obiectul creat va fi stocat în tabela de obiecte Persoane (figura 9.5 ). 


- ca o tabelă cu un singur atribul. Fiecare tuplu al tabelei este un obiect de tip 
| I. Pe această tabelă se pot executa operaţii orientate obiect. De exemplu, se execută 
pe tabela Persoane utilizând funcţia VALUE() ce returnează un obiect : 


VALUE(p) FROM persoane p WHERE p prenume = 'Dan 


Obiectele ce sunt stocate ca tupluri într-o tabelă de obiecte se numesc obiecte-tuplu, 
obiectele ce sunt stocate ca atribute într-o tabelă sau sunt atribute ale altor obiccte se 
obiecte-coloană. 

Se pot defini restricţii pe atributele unui tip sau pe o tabelă de obiecte. De exemplu, se 
tipul locatie_ şi tabela de obiecte locaţie, Se defineşte o restricție de cheie primară 
tabela locaţie: 


Create table, Lian da of persoana 1 
insert into persoane values (persoana t (2110461123400, 'Ionescu', 'Doina', 3440244)) 


ppe locatie t as object(cod cladire number, denumire varchar2(20) ) 
table locatie of locatie t (cod cladire primary key ) 


In unele situații se impune utilizarea alias-urilor pentru tabele, De exemplu, se 
Vine tabela de obiecte persoane și tabela Curs ce conține atributul profesor de tip 


create Table curs 
(curs id varchar2(10), curs denumire varchar2(20), profesor student.persoana 1) 


Următorul exemplu utilizează un alias pentru tabelă. Atributul CNP este un atribut a 
unui obiect de tip persoana t — obiect stocat în coloana Profesor. Denumirea atributului 
trebuie precedată de denumirea coloanei si de alias-ul tabelei (figura 9.6 ): 


select c profesor.enp from curs c 


Fig. 9.5. Utilizarea metodei constructor 


9. 2. Tabela de obiecte 


gel de ec re m o pasii ds het einst. ml recs s e 
obiect. De exemplu, tabela Persoane va stoca obiectele tipului Persoana_/. Această tabelă 
poate vizualiza în două moduri: 

- ca o tabelă cu mai multe atribute - atributele tipului Persoana 1. Pe această tabelă se 
uk. v ORA aceata: De exemplu, se adaugă un obiect de tip persoana 1 în tabela 
'ersoane 


insert into persoane values ( persoana 1(1670603400129, 'Nicolae', "I 


', 16485361)) 


- + Tazeen rai 
Fig. 9.6. Utilizarea unui alias pentru tabelă 
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În următorul exemplu nu se utilizează un alias pentru tabelă, atributul CNP este un 
atribut al tabelei persoane: 


select cnp from persoane 


9.3. Tehnica de referire a obiectelor 


Tehnica de referire a obiectelor este similară cu restric[ia de cheie extemă din modelul 
relational. REF este un pointer logic la un obiect-tuplu, construit din identificatorul (object 
identifier-OID) obiectului referit şi oferă un mecanism simplu pentru navigare între obiecte. 
Se poate modifica o referire (se face referire la alt obiect al aceluiași tip) sau i se poate asocia 
valoarea null. De exemplu, se creează tipul Angajat 1 1. Un obiect de acest tip se caracterizează 
prin atributele mume şi sef. Atributul Sef va stoca referiri către alte obiecte ale tipului 
Angajat t. Altfel spus un angajat are un nume (de exemplu Dumitru Ion) și un şef ierarhie 
superior (de exemplu Ionescu Diana). Șeful este şi el un angajat, deci un obiect de tip 
Angajat t: 


1 
create type angajat t as object (nume varchar2(30), sef ref angajat. 1 ) R 


Obiectele de tip angajat. t vor fi stocate în tabela Angajat obj tabela: 


ie tabl i| bj tabeh $ te ta von moms Br pma sae Ios bmp 
create table angajal_âbj_tabela of angajat t ; S2eg o9. 9. : 
Angajatul Ionescu Diana nu are şef sau altfel spus se specifică valoare null pentru 
obiectul referit: 


4 

insert into angajat obj tabela values ( angajat t (Ionescu Diana’, null)) 
Atributul Sef al obiectului Dumitru Jon va stoca referirea către obiectul Ionescu Diana, 

(şeful lui Dumitru Ion este Ionescu Diana) (figura 9.7): 


H 


insert into angajat obj tabela select angajat 1 $ (Dumitru lon', REF(a)) from 
angajat obj tabela a where a.nume = 'lonescu Diana' 


Operatorul REF se utilizează pentru a retuma referirea unui obiect-tuplu. Este posibil 
ca obiectul referit să nu mai fie valabil datorită ştergerii lui sau anulării drepturilor. zu» 
referire se numeşte izolată (dangling). Se pot evita aceste situaţii prin definirea de restricţii de, 
integritate. 

Pentru a afișa numele șefului unui angajat, se poate utiliza comanda (figura 9.8) : 


Select a.nume, a.sef nume from angajat, obj tabela a where a.nume== Dumitru lon! 


În acest exemplu, a.sef.nume foloseşte referirea specificată atunci când s-a creat 
angajat_obj_tabelă şi returnează numele şefului. Este permis numai în SQL, nu si în PL/SQL: 
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9.4. Moştenirea 


„Conceptul de moştenire este suportat de Oracle începând cu versiunea 9i. Anterior 
acestei versiuni, moștenirea era implementată utilizând asocieri cheie primară-cheie extemă 
ia PENEAN EN suge a aed lasă si subclasele ei). In figura 9.9 se prezintă un exemplu 

le m. in care obiect al supertipului Pers t aparţine cel puţin unui subtip. 
persoană poate fi angajat si student. AJ 


p € 
| angaj t 
J&pfoncia 
|&psalariu. 
| i 


Fig. 9. 9. Un exemplu de moştenire 


9.4.1. Implementarea mostenirii in Oracle anterior versiunii 9i 


Se va crea o tabelă pentru superclasa Pers f şi pentru fiecare din, subclasele sale: 
Student. 1 şi Angaj t. Pentru a simula moştenirea, tabelele Studenti si Angajati vor “moşteni” 
cheia primară a tabelei Persoane. Cheile externe ale tabelelor Angajati şi Studenti sunt si chei 
primare. Se asigură astfel că fiecare student si fiecare angajat este de asemenea, o persoană. 


Create table persoane (marca number(4) not null, nume varchar2(20), 
data nasterii date, Primary key(marca)) 


Create table studenti(marca number(4) not null, specializare varchar2(20), 
an studiu varchar2(4), Primary key(marca), 
Foreign key(marca) references persoane on delete cascade) 


Create table angajati(marca number(4) not null, salariu number, 


functia varchar2(20), Primary key(marca), 
Foreign key(marca) references persoane on delete cascade) 


278 


4.2. Implementarea moştenirii utilizând clauza “under” 


Începând cu versiunea 9i, moştenirea este implementată utilizând clauza "under" 
“atunci când se creează subtipurile Student 1 şi Angaj 1. Pentru a implementa subtipuri, trebuie 
să definim tipurile ca "not fina“. În mod implicit tipul va fi tratat ca "final" si nici un subtip 
“au poate fi derivat din acest tip. Pentru fiecare subtip se va crea o tabelă de obiecte. De 

asemenea, se va crea o tabelă de obiecte pentru supertipul Pers t pentru a stoca persoanele 
care nu sunt nici studenți, nici angajaţi (de exemplu sunt colaboratori): 


"Create or replace type pers t as object 
"marca number(4), Nume varchar2(20), Data. nasterii date) not final 


" Create table persoana of pers 1(marca primary key) 
E 

Create or replace type student. t under pers t 

" (specializare varchar2(20), an studiu varchar2(4)) 


"Create table student of student. t(marca primary key) 


"Create or replace type angaj. t under pers 1 
Galariu number, functia varchar2(20)) 


Create table angajati of angaj (marca primary key) 


943. Moștenirea multiplă 


= “Oracle suportă numai moştenire simplă. Clauza "under * este utilizată numai 
moştenire simplă. Totuşi conceptul de moştenire multiplă este adesea simulat utilizând alte 
tehnici existente. De exemplu, se poate utiliza clauza “under” pentru a implementa un părinte 
moştenit şi se utilizează un tip de asociere pentru a lega subclasa de celălelt părinte. Problema 
este că numai părintele implementat utilizând clauza “under” poate fi moştenit şi de aceea 
_ trebuie să fim atenţi care părinte este moştenit si care este asociat. 


9, 5. Relaţii de asociere 


i În Oracle există două moduri de implementare a asocierilor între clase: 
- prin cheie primară şi cheie externă. Stabilirea cheilor externe se bazează pe 
cardinalitatea asocierii între entitățile modelate (1:1, 1:m, m:m). Se va utiliza diagrama 

- deelase din figura 9.10. 
+ Asocierea dintre clasele Student ( si Curs_t este de tip (mz). La implementare, se va 
crea o tabelă intermediară Inscriere. Cheile primare ale celor două tabele Student şi Curs 
X migrează în tabela intermediară Inscriere sub formă de chei exteme si împreună formează 
„cheia primară a acestei tabele. Asocierea dintre clasele Profesor 1 si Curs 1 este de tip (1m). 
La implementare, cheia primară a tabelei Profesor devine cheie externă pentru tabela Curs. 
Asocierea dintre clasele Profesor. t şi Birou 1 este de tip (1:1). La acest tip de asociere trebuie 
S se stabilească obligativitatea participării la asociere a celor două clase: obligatoriu/optional. 
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In exemplul dat, fiecare profesor trebuie să fie localizat într-un singur birou (deci 


Pe de altă parte, un birou poate fi liber (participarea clasei Birou în asociere este opțională. p 
La implementare, cheia primară a tabelei Birou devine cheie externă a tabelei Profesor. 


Fig. 9.10. Un exemplu de diagramă de clase implementată în Oracle 3 

Utilizarea restricţiilor de integritate referențiale determină o validare automată în 

tabela referită, înainte de a se executa operaţia de manipulare în tabela care referă. Se pot. 

adăuga politici de reacţie (cascade, restrict şi nullify) prin restricțiile referenfiale definite sau 

prin triggeri: di E 
Create table student 

(nrmatricol mumber(4) not null, nume varchar2(20), Primary key(nrmatricol)) 


Create table Birou(cod varchar2(10) not null, den cladire varchar2(20), Primary key(cod)) < 


f: 
Create table profesor(marca mumber(4) not null, nume varchar2(30), cod varchar2(10), 
Primary key(marca), Foreign key(cod) references birou (cod) on delete cascade) i 


Create table curs (cod curs varchar2(10) not null, denumire varchar2(30), marca number(4), 1 
Primary key(cod curs), Foreign key(marca) references profesor (marca) on delete cascade) 
Create table inscriere(cod curs varchar2(10) not null, marca number(4) not null, 
Primary key(cod curs, nrmatricol), 
Foreign key(cod curs) references curs(cod curs) on delete cascade, 
Foreign key(nrmatricol) references student(nrmatricol) on delete cascade) 

S prin tehnica de referire a obiectelor, În loc de a asocia două tabele prin valorile cheii 
Pos i MDH extstue ascelate,mocastă tehnică permite legătura directă a două tabele prin. 


Implementarea asocierii (m:m) dintre clasele Student si Curs, utilizând atribute de, 
referire se realizează astfel (figura 9.11): și 


~se creează tipul student t 
Create or replace type student 1 as objeci(nrmatricol number(4), Nume varchar 2(20)) 
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I —————————— 
se creează tipul curs 1 

Create or replace type curs. t as object 

(cod. curs varchar 2(10), denumire varchar2(30)) 


se creează tabela de obiecte student care va stoca obiecte de tip student. t 
Create table student of student t(nrmatricol Primary key) 


_ se creează tabela de obiecte curs care va stoca obiecte de tip curs 1 
Create table curs of curs t(cod curs Primary key) 


se creează tabela inscriere. Atributul student va stoca referiri la obiectele de tip student. 1, 
iar atributul curs va stoca referiri la obiectele de tip curs_1 
Create table inscriere(student ref student 1, Curs ref curs 1) 


Implementarea asocierii (1:m) dintre clasele Profesor 1 si Curs t utilizând atribute de 
referire se realizează astfel (figura 9.12): 


„se creează tipul profesor t 
Create or replace type profesor. t as object(marca number(4) nume varchar2(30)) 


se creează tipul curs f. Atributul profesor va stoca referiri la obiectele de tip profesor t 
Create or replace type curs t as object 
(cod. curs varchar2(10), denumire varchar2(30), profesor ref profesor 1) 


-~se creează tabela de obiecte profesor 
Create table profesor. of profesor. i(marca Primary key) 


-se creează tabela de obiecte curs 
Create table curs of curs t(cod curs Primary key) 


Implementarea asocierii (1:1) dintre clasele Birou 1 şi Profesor. t utilizând atribute de 
referire se realizează astfel (figura 9.13): 


~se creează tipul birou 1 
Create or replace type birou. t as object(cod varchar2(10), den cladire varchar2(20)) 


~se creează tipul profesor 1. Atributul birou va stoca referiri la obiectele de tip birou f£ 
Create or replace type profesor t as object 
(marca number(4),nume varchar2(30), birou ref birou, 1) 


~se creează tabela de obiecte birou 
Create table birou of birou t(cod Primary key) 


~se creează tabela de obiecte profesor 
Create table profesor of profesor. t(marca Primary key) 


Utilizarea tehnicii de referire a obiectelor nu implică nici o restricție de integritate. 
teferenţială. De asemenea, există posibilitatea ca o referire să fie “izolată” dacă obiectul 
referit este şters. Pentru a evita această situaţie se poate adăuga o restricţie referențială. 


E 


Fig. 9.12. Implementarea asocierii (1:m) utilizând atribute de referire 
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9.6. Agregarea 


Oracle oferă două tehnici pentru implementarea agregărilor: tehnica cluster şi tehnica 
tabelelor imbricate. 


9.6.1. Implementarea agregării utilizând tehnica cluster 


- — Clusterul este un grup de două sau mai multe tabele stocate fizic împreună, deoarece 
au atribute comune şi sunt adesea folosite împreună în jocfiuni. Deoarece tuplurile corelate 
Sunt stocate fizic împreună, timpul de acces se îmbunătăţeşte. Tehnica cluster se utilizează 
pentru a implementa agregarea compusă In figura 9.14, între clasa Facultate t şi clasa 
Catedra t există o agregare compusă (agregarea exclusivă în care existența obiectelor "parte 
depinde complet de obiectul “întreg'“). 

| Agregarea compusă se implementează prin definirea unei chei primare compuse ce 
include si cheia cluster, pentru tabela “parte” Catedra şi utilizarea cheii cluster drept cheie 
extemă. Tuplurile tabelei Facultate si tuplurile tabelei Catedra sunt stocate fizic împreună. 
Indexul pentru cluster este creat în scopul de a îmbunătăţi performanţa stocării clusterului: 


“se creează cluster-ul Fac, cluster, iar atributul cod fac este cheie cluster 
„Create cluster fac. cluster(cod fac varchar2(5)) 
f. creează tabela Facultate corespunzătoare clasei "intreg^ Facultate t şi este inclusă in 


cmd table facultate. 
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(cod fac varchar2(5) not null, den fac varchar2(30), decan varchar2(30), 
Primary key(cod fac)) Cluster fac cluster(cod fac) 


--se creează tabela Catedra corespunzătoare clasei "parte" Catedra t si este inclusă in cluster 
Create table Catedra(cod fac varchar2(5) not null, cod cat. varchar2(5) not null, rd 
varchar2(50), Sef catedra varchar2(30), Primary key(cod fac, cod cat), 

Foreign key(cod fac) references facultate(cod fac)) Cluster fac cluster(cod fac) 


se creează indexul pentru cluster 
Creare index fac_cluster_index on cluster fac_cluster 


9.6.2. Implementarea agregării utilizând tehnica tabelelor 1 
imbricate | 
! 

Această tehnică este utilizată numai pentru implementarea agregării compuse. Dacă 
obiectul “intreg” este şters, toate obiectele "parte" asociate vor fi şterse. În tehnica tabelelor 


imbricate se poate adăuga o nouă înregistrare “parte” în tabela imbricată, numai dacă exist 
înregistrarea “întreg” corespunzătoare. Se va utiliza exemplul din figura 9.14. 


se creează tipul Catedra_! 
Create or replace type catedra t as object 
(cod cat varchar2(5), den. cat varchar2(50), sef catedra varchar2(30)) 


~se creează tipul Catedra tabela (tip colecţie) 
Create or replace type catedra tabela as table of catedra t 


se creează tipul Facultate f. Pentru acest tip se defineşte si o metodă şi anume 
afiseaza catedre care va fi apoi utilizată într-un bloc PL/SQL. Atributul catedra este de 


colecţie. 

Create or replace type, * t as object(cod fac varchar2(5), 
den fac varchar2(50), decan varchar2(30), catedra catedra_tabela, 
member procedure afiseaza_catedre (self in out nocopy facultate 1)) 


Oracle-SGBD obiectual relational 


~se creează tabela de obiecte Facultate tabela în care se vor stoca obiecte de tip facultate. 1. 
Informaţiile despre catedre sunt stocate in tabela imbricată catedra tab 

Create table facultate tabela of facultate t 

(primary key(cod fac) ) Nested table catedra store as catedra tab 


— se defineşte corpul metodei afiseaza catedre utilizând limbajul PL/SQL. Procedura 
2 catedre utilizează un cursor explicit c_caledra, precum şi o structură repetitivă 

pentru a selecta şi afișa informaţii despre catedrele corespunzătoare obiectului de tip 
+ specificat ca parametru : 

create or replace type body facultate_ as 

Member procedure afiseaza catedre(self in out nocopy facultate 1 ) is 
Cursor c. catedra is select den cat, sef catedra 
from the (select catedra from facultate tabela where cod. facself.cod fac); 


Begin 
dms ouiputput line(cod fac|' ^ '|den fac ); 
dms output.put line("Decan: "|decan); 


Dbms output.pul line 

('Catedra"|" 1|'sef catedra’); 

Dbms output. put line(" 

For v catedra in c. catedra loop. 

Dbms output.put line(v catedra.den cat||" 
End loop; 

End; 

end; 


D: 


"|v_catedra.sef catedra); 


~un tuplu în tabela facultate tabela se adaugă astfel 

INSERT INTO facultate_tabela VALUES 

('CSIE' "Cibernetica, Statistica, Informatica Ec! null, 

catedra_tabela(catedra_1(1E', "Informatica Ec', "Bogdan Ghilic'), 

catedra_1('CIB'. "Cibernetica Ec’, NULL), catedra 1(STAT" 'Statistica Ec". null))) 


Următorul bloc PL/SQL selectează facultatea CSIE şi execută procedura 
afiseaza_catedre a tipului facultate t pentru a afişa catedrele acelei facultăţi (figura 9.15). 
Funcţia VALUE() returnează un obiect de tip Facultate 1: 


declare 
Facultate facultate t; 
begin 


select value(f) into. Doer from facultate tabela f where f.cod fac = 'CSIE': 
Praec catedre; 


ena sta rea e 
.15. Exemplu de utilizare a unei metode într-un bloc PL/SQL 


9.6.3. Implementarea agregării simple 


În figură 9.16 se prezintă o agregare simplă între clasa “întreg ^ Catalog t si clasa 
“parte” Adidas. t. Un obiect "parte" (de exemplu “Adidas Racer", cod 3395081) se poate găsi 
în cataloagele diferitelor magazine cu profil sportiv. 

In tehnica rabelelor imbricate se poate adăuga o nouă înregistrare “parte” în tabela 
imbricată, numai dacă există înregistrarea “întreg” corespunzătoare. Din acest motiv, pentru 
acest tip de agregare se poate utiliza o combinaţie între tehnica tabelelor imbricate si tehnica 
de referire a obiectelor: 


-se creează tipul adidas. t şi tabela de obiecte Adidas rabela în care se vor stoca obiecte de 
tip adidas. : 

Create or replace type adidas. t as object 

(cod number, denumire varchar2(30), culoare varchar2(30)) 

create table adidas tabela of adidas t(primary key(cod)) 


se creează tipul Lista (tip colecție): 
Create or replace type lista as table of ref adidas t 


se creează tipul Catalog, t. Atributul adidas este de tip colecţie: 
Create or replace type catalog t as object (cod number, 
denumire varchar2(30), sezon varchar2(30), an varchar2(4), adidas lista) 


se creează tabela de obiecte Catalog tabela. In tabela imbricată Adidas fab se stocheaz 
referirile la obiectele de tip adidas 1: 
create table catalog tabela of catalog t (primary key(cod cat)) 

Nested table adidas store as adidas tab 
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Fig. 9.16. Agregare simplă 


~se adaugă următoarele tupluri în tabela adidas. fabela: 
Insert into adidas_tabela values(adidas 1(3395081, 'Adidas Racer’, 'alb')) 
Insert into adidas. tabela values(adidas 1(3397016, 'Adidas Racer’, 'negru alb) 


~se adaugă un catalog in tabela Caralog_tabela: 
insert into catalog, tabela values(1, 'OTTO', 'primavara', '2007' lista) 


~ tabela imbricatà specificată de funcția TABLE() va stoca referirile la produsele prezentate 
În acest catalog: 

insert into table(select c.adidas from catalog tabela c where c.cod_cat=1) 

select refía) from adidas. tabela a where a.cod-3395081 

insert into table(select c.adidas from catalog. tabela c where c.cod cat1) 

select ref(a) from adidas tabela a where a.cod=3397016 


Implementarea agregării multi-nivel utilizând tabele 
imbricate 


. SGBD-ul Oracle permite tabele imbricate pe mai multe nivele care pot fi utilizate pentru a 
implementa o ierarhie de agregare multi-nivel. De exemplu, între clasa Regiurie_1, clasa 
Judet t şi clasa Oras t există o ierarhie de agregare multi-nivel: 


75e creează tipul Oras 1: 
Create or replace type oras. t as object 
(denumire. oras varchar2(30), populatie number) 


55e creează tipul Oras tabela (tip colecţie): 
Create or replace type oras_tabela as table of oras t 


E 


(556 creează tipul Judet. t. Atributul oras este de tip colecţie: 
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Create or replace type judet t as object 


Gudet_id varchar2(3), denumire judet varchar2(30), oras oras. tabela) 


--se creează tipul judet tabela (tip colecţie): 
Create or replace type judet_tabela as table ofj Cjudet t 


75e creează tabela Regiune_tabela. Atributul judet este de tip colecţie. Tabela imbricag 


judet_tab include o altă tabelă imbricată oras ab: 


Create table regiune_tabela(Denumire_regiune varchar2(30) primary key. 
Judet judet_tabela) Nested table judet store as judet tab. 


(nested table oras store as oras. tab) 


--un tuplu in tabela Regiune_rabelă se poate adăuga astfel: 


insert into regiune_tabela values('Dobrogea', 
 Judet tabela(judet t('CT", 'Constanta', oras_tabela 


(oras t('Cernavodu', 10000), oras. t Mangalia’, 10000))))) 


--tuplul adăugat anterior se poate afişa (figura 9.17): 


SELECT r.denumire regiune, j.denumire judet, o.denumire oras FROM 
TABLE (r judet) j, table(.oras) o where r. Demmire_regiune ="Dobrogea' 


regiune tabelar,. 


[ 
[mmm segia atata T 
jue e. Ponti saga Senece 


ksa- 2} 
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Baze de date distribuite 


Capitolul 10 
Baze de date distribuite (BDD) 


10.1 Definiţie şi obiective 


10.1.1 Definiţie 


Generalizarea utilizării calculatoarelor în toate domeniile economico-sociale generată, 
pe de o parte de acumulările cantitative şi, pe de altă parte, de explozia în dezvoltarea de noi 
tipuri de sisteme de calcul accesibile la nivel individual (personal) determinată de producerea 
unor microprocesoare din ce în ce mai performante, a dus implicit la posibilitatea emulării 
oricărui nivel de producere şi utilizare a informaţiilor prin rețele de calculatoare (rețele locale, 
reţele ale unor ramuri de activitate, rețea naţională, rejele private virtuale pe Internet). 

Acest lucru a făcut posibilă şi oportună utilizarea bazelor de date distribuite (BDD). 
Bazele de date distribuite au răspuns unei necesități pragmatice de gestiune a datelor: cle 
răspund cererii ca arhitectura managementului datelor să se adapteze necesităţilor de producere 
şi utilizare a datelor în întreprinderi, care suni în mod natural, structural distribuite. 

Evoluţia progresivă a unui sistem informatic în curs de exploatare cere din partea sa 
supleje în ceea ce priveşte adăugarea, suprimarea 
sau modificarea dinamică a uneia din 
componentele sale fără a perturba grav ansamblul 
acestuia. Sistemele distribuite pot fi configurate 
prin adăugiri şi modificări progresive ale 
componentelor cu un înalt grad de flexibilitate şi 
modularitate (faţă de sistemele bazate pe utilizarea 
centralizată a resurselor — mainframe — care sunt 
mult mai rigide). 

Definiţie: O Bază de date distribuită (BDD) este o 

bază de date (BD), logic integrată, dar fizic 

distribuită pe mai multe sisteme de calcul 

: : a distincte, interconectate între ele. 

Fig. 10.1 Interacțiunea utilizator - BDD în cele ce urmează vom prezenta cele două 
subliniate în definiţie împreună cu 


noțiunile/conceptele care concură la definirea lor. 

Logic integrată. O bază de date distribuită este caracterizată prin prezența a cel puţin două 
servere de baze de date care pot prelucra independent unul de celălalt tranzacții locale. Din 
punctul de vedere al utilizatorului BDD reprezintă o singură BD. Abstractizând, o bază de date 
distribuită, poate fi considerată o colecţie unică de date iar serverele de baze de date garantează 
Programelor de aplicaţie accesul la resursele de date oferind utilizatorului exact același tip de 


| 


interacţiune ca cea utilizată la sistemele centralizate. BDD are o singură schemă conceptuală 
globală iar utilizatorul interacționează cu BDD în aceeași manieră in care interacționează cu o 
BD centralizată/locală si, în general, nu are informaţii despre partiţionarea, replicarea şi 
distribuirea datelor. Prelucrările initiate la un nod antrenează in general prelucrarea informaţii 
aflate în alt nod (figura 10.1). În această figură este o bază de date distribuită formată 
din Bazele de date locale (BDL) BDL, BDLa, BDL; stocate în nodurile unei rețele notate 
(corespondent) Ni, Nz şi respectiv Ns. Aceste baze de date locale, definite prin rehnica 
fragmentării, se integrează în baza de date distribuită prin intermediul unei scheme globale (SG, 
la care va face referire orice utilizator global (UG). Fragmentarea datelor este o tehnică utilizan 
pentru organizarea datelor în scopul asigurării unei distribuții eficiente a datelor şi prelucrărilor, 
Această tehnică este aplicabilă numai dacă distribuirea datelor urmează o schem bine definită 
care este utilizată pe întreaga durată de proiectare a bazei de date distribuite. 

Un utilizator local (UL) reprezintă un utilizator dintre oricare din tipurile de utilizatori ai 
bazelor de date care are acces si exploatează o bază de date locală. El cunoaște si manipulează 
numai schema acelei baze de date locale (sau o subschemă a bazei de date locale). Manipularea 
bazei de date locale include oricare din bazele de date locale din reţea (chiar dacă aceasă 
manipulare se cfectueaz cu terminal virtual, de exemplu un utilizator din nodul Ni exploatează 
baza de date aflată in N, utilizând numai facilităţile puse la dispoziţie de software-ul de rețea). 

Un utilizator global (UG) aparine oricărui tip din gama de utilizatori ai bazelor de date 
cu singura diferenţă că el cunoaşte si are acces la schema (sau o subschem) bazei de da 
globale. Utilizatorul global exploatează schema globală (sau subschema) conform autorizărilor 
şi drepturilor sale de acces de aceeași manieră în care ar lucra cu o baza de date locală (sau 
centralizată). 

Baza de date distribuită (o mulțime de colecții de date şi legăturile dintre ele) este 
fragmentată conform principiilor: 

- plasarea datelor memorate în nodul de producere si utilizare a lor; 

- minimizarea transportului de date prin reţeaua de calculatoare. 

Pentru a răspunde acestor principii fragmentarea se realizează la două nivele: 

-  partiţionarea mulțimii (ansamblului) de colecţii de date în submulțimi 

(subansambluri) de colecţii de date; 
- partiționarea unei colecţii de date în fragmente. 
În acest paragraf vom defini formal fragmentarea si tipurile de fragmentări. Fie o relaţie 
cu schema R. Fragmentarea lui R constă în determinarea unui anumit număr de fragmente 
(subscheme) R, obținute prin aplicarea unei relaţii algebrice lui R (ca operaţii pe relaţii care 
exprimă proprietăţi logice ale datelor). În acest context fragmentarea colecţiei de date se poste 
realiza în două moduri: 
~ orizontal - fragmentele rezultate R; au aceeaşi schemă de structură ca si colecţia R, 
dar diferă între ele prin datele pe care le conţin (in mod normal sunt colecţii 
disjuncte) si sunt, în mod natural, rezultate ca urmare a aplicării unei selecţii pe R; T 

- vertical - fragmentele rezultate R; conțin doar o parte, fiecare, din structura colecţiei 
R Ele contin cheia primară a relaţiei R pentru a asigura restaurabilitatea si sunt, în 
mod natural, rezultate ca urmare a aplicării unei proiecţii pe R. 

Este admisă şi combinarea celor două moduri (fragmentare mixtă). 

Fragmentele rezultate constituie elementele de distribuire a datelor. Fragmentarea este 
corectă dacă sunt valide următoarele proprietăți: 

-  Completitudine (completeness) — orice atribut din R trebuie să se regăsească cel 

puţin într-unul din fragmentele R;; 

- Recompunere (restorability-restaurabilitate) — conținutul lui R trebuie să poată fi 

refăcut (restaurav/restaurabil) din fragmentele sale. 
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cute greieri ere MP onorate pe un nod al relet si 

sonate de acelaşi SGBD, formează o bază de date locală — 

f Fiecare fragment Ri poate corespunde unui fişier fizic diferit şi poate fi alocat pe un 
duh 


Fizic distribuită pe mai multe facilităţi de calcul distincte, aceasta însemnând că: 

- baza de de e partitionat& iar pariţiile/fragmentele respective sunt stocate pe 
calculatoare diferite (se admit copii ale fragmentelor memorate în noduri diferite). 

- fiecare fragment este văzut, în nodul în care există, ca o bază de date centralizată, 
care poate fi exploatată şi administrată local. z " 

Sistemul trebuie să asigure trensparenfa fragmentării şi a alocárii. Transparenţa 

= ii se referă la faptul că programatorul nu trebuie să se preocupe de faptul că baza de 
este distribuită gi are relaţii fragmentate. Cererea pe care o adresează el trebuie să fie 


că programatorul 
parte, trebuie să fie liber să poată indi 
localizării (acest lucru este asigurat pri 
Sistemul trebuie să asi, i atomicitatea tranzacţiei lizat i 
Sem ce acceseazl și actualizeaza date aflate în diferite situri în acelaşi mod în care 
scrie tranzacții pentru o bază de date locală. 

E najuncs car « condis le ifia bazelor de date dsitribuite nu a fost reprezentată de 
maximizarea interacțiunii şi transmisiei datelor în rețele de calculatoare ci de a modela cát mai 
bine datele companiilor şi interdependenpele dintre ele pentru a permite rularea a cát mai multor 
aplicaţii independente pe un singur server astfel încât să se reducă costurile mari necesitate de 


de date distribuită poate utiliza o rețea | 
o reţea pe arie extinsă (WAN — Wide Area 
aplicaţii tipice în cazul acestei clasificări. 


Tabelul 10.1 Exemple de aplicaţii tipice de BDD în funcţie de tipul de SGBD utilizat i tipul de 


Tij de calculatoare 
LAN WAN Ta 
Gestiunea datelor şi aplicaţii | Management transport si aplicații 
Sisteme informatice inter- Systeme bancare integrate şi sisteme 


: Systems — Concepts, Languages and Architectures , Atezeni, Ceri, 
p Paraboschi and Torlone, McGraw and Hill, 1999 

x cazul ii SGBD-uri diferite care accceptà numai “dialectul” lor SQL ne 
Som ues E. acies a transparenţei iar programatorul va fi obligat să specifice în 
„ Cerere fragmentele si alocarea lor în sistem. 
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a bazei de date distribuite acest lucru nu trebuie să influențeze aplicaţiile si schema 

10.1.2. Obiectivele sistemelor de baze de date distribuite „conceptuală globală. supe deeper 

einlizate. În BDD rezolvirile găsite nu au fost de la început pe deplin satisfăcătoare. De 

emplu, independența datelor trebuie asigurată mu numai la nivelul nodului local ci trebuie să 
demmità o posibilă relocare a datelor în noduri. k a T 

În afara acestor probleme comune BDD si BD centralizate au apărut și altele noi ca: — 

-~ prevenirea creşterii redundanjei sau a inconsistenfei datelor la dezvoltarea de noi 


În concordanță cu definiția dată în $10.1.1 sistemul de baze de date distribuite trebuie 
asigure următoarele obiective € 
- transmiterea datelor la utilizatorii lor: indiferent care este nodul în care se află y 
utilizator şi indiferent unde sunt stocate datele (localizate) acesta trebuie să-și poată 
obține informațiile de care are nevoie (numai cu condiţia să aibă dreptul şi 
autoritatea de a le accesa); 
evitarea unei foarte înalte centralizări a resurselor (centralizare care cauzează 
foarte mult eficienţei si eficacităţii sistemului): o rată înaltă a centralizării resurselor 
poate provoca un cost ridicat de prelucrare si transmitere a datelor la utilizatori; -. 
- - să sporească durabilitatea sistemului: pot fi introduse în orice moment noi structui 
de baze de date (pot fi integrate baze de date noi) prin includerea schemei lor în 
schema conceptuală globală fără a afecta aplicaţiile existente; x 
să facă mai ușoare operaţiile de menţinere yi restructurare a bazei de date cu 
menţinerea unei rate înalte a disponibilităţii: deoarece ceea ce vede un utilizator 
global reprezintă o schemă globală, care are drept corespondent diverse scheme 
locale, operația de restructurare a unei scheme locale nu trebuie să afectează cu 
nimic utilizatorul global; z 
- să permită proiectarea structurii organizatorice şi funcţionale a sistemului analizat: 
prin faptul că, în general, bazele de date locale se află în locurile în care se produc 
informaţiile pe care le conţin o arhitectură distribuită permite o emulare mai 
puternică, a sistemului informaţional, conformă structurii organizatorice şi 
funcţionale; e 
- să mărească gradul de utilizare al sistemului: prin emularea cadrului organizatorie 
şi funcţional şi prin disponibilitatea datelor se obține creşterea numârului de 
utilizatori ai sistemului. 


- Mts de insructhai pentru standarde de definire i utilizare a datelor; 
- administrarea eficientă a cererilor; , Y 
- utilizarea eficientă a resurselor de telecomunicafie (reţelei de calculatoare) etc. 


E 


Aceste obiective atrag după sine rezolvarea unor probleme tehnice care se referă la: 


Fig. 10.2 Arhitectura SGBDD 


10.1.3. Baze de date relafionale distribuite 


i tabele) 
O bază de date relațională distribuită (BDDR) constă dintr-o colecție de relații (t 
fiecare din cle putind fi stocat Intr-un singur nod al rețelei sau putnd fi ispéndit într-o eet 
de calculatoare numite in acest caz relaţii distribuite. " : 
Fiecare relație distribuită poate fi fragmentată orizontal, vertical sau mixt în acord cu un 
criteriu de distribuire. ' s 
Lose ck deseri 3 grupuri a. O relație este locală dacă este stocată în întregime pe un singur nod şi global dacă 
proscris nieder deese ce aiam frsgmentele sale sunt stocate în diverse noduri ale rețelei de calculatoare. : 
nodu il PERENNE Eren ele OMM Avantajul utilizări bazelor de date distribuite este dat de faptul cà sistemul de gestiune a 
pra: precii logice, bazelor de date distribuite (SGBDD) funcţionează ca un sistem centralizat în timp ce fizic se 
Herren edet apr iania adaptează repartitiei componentelor unei întreprinderi sau administrari. | as 
iecur, s e În iata de dece ictum n figura 102 este prezentată arhitectura unui sistem de gestiune a bazelor de 
lapi ires în coro esie stocată o parti distribuite (SGBDD). 


10.1.4 Arhitectura sistemelor de baze de date distribuite 


Arhitectura prezentată în figura 10.2 este propusă de raportul ANSUSPARC prin care 
sistemul de gestiune a bazelor de date distribuite este subdivizat în niveluri de descompunere. 
trecerea de la un nivel la altul efectuându-se prin procese de corespondențe si transformare. În 
această schemă avem două niveluri de organizare a datelor: 
- nivelul global ca element ce permite integrarea bazelor de date locale într-o bază de date 
globală; 
- nivelul local ca element care permite tratarea fiecărei baze de date locale, incluse în baza 
de date distribuită, ca pe o bază de date centralizată. 

Un utilizator global interacționează cu baza de date distribuită de aceeași manieră cu 
care ar interacţiona cu o bază de date centralizată. El isi exprimă cererile sale (de la 
terminale/PC-uri cuplate on-line sau prin programe de aplicaţie) sub formă de tranzacţii globale. 
Aceste tranzacții globale sunt evaluate şi prin intermediul informaţiilor conţinute în 
dicţionarul sistemului distribuit (DSD) şi sunt transmise supervizorului execuţiei distribuite. 
Acesta are rolul de a transmite fiecare cerere nodului pe care se află baza de date locală pe care 
trebuie să o interogheze şi, pe de altă parte, de a primi răspunsurile de la diverse baze de date 
interogate si a forma răspunsul pentru tranzacţia globală. 

Deoarece diversele baze de date locale pot avea sisteme de gestiune diferite şi mai mult 
calculatoarele din reţea pot fi neomogene este necesară realizarea unei adaptări, a fiecărui 
fragment al cererii globale, conforme cu protocolul fiecărui sistem de operare si fiecărui SGBD 
specific din fiecare nod. După adaptarea cererii la standardele cerute de SGBD-ul nodului local 
acesta va trata cererea ca pe orice cerere locală. ă 

Tranzacţiile pot fi clasificate în diverse categorii în funcţie de criteriile de clasificare 
considerate. De exemplu, dacă se are în vedere numai fragmentarea datelor, toate cererile 
adresate sistemului distribuit sunt cereri distribuite. 

Considerând tipurile instrucțiunilor SQL din care sunt construite (conform clasificării 
sugerate de IBM şi adoptate si de alţi realizatori de SGBD) si localizările datelor cererile pot fi 
clasificate astfel: 

- cereri la distanță (remote requests) sunt tranzacții numai în citire (read only) 
construite dintr-un număr arbitrar de comenzi de selecţie (select) adresate unii 
singur SGBD la distanţă; 

= tranzacţii la distanță (remote tranzactions) sunt tranzacții formate din orice tipuri 
de comenzi SQL (select, insert, delete, update) si adresate unui singur SGBD l2 
distanţă; 

- tranzacții distribuite (distributed transactions) sunt tranzacții formate din oricâte şi 
orice tipuri de comenzi SQL (select, insert, delete, update) adresate unui numit 
oarecare de SGBD la distanţă cu fiecare comandă adresându-se datelor stococate 
de un singur SGBD; 

- cereri distribuite (distributed requests) sunt tranzacţii arbitrare formate dintr-un 
număr arbitar de comenzi SQL de tipuri diferite care se referă la date stocate de 
diverse SGBD-uri. 

Înainte de execuţie, pentru cererile distribuite, se aplică de câtre majoritatea SGBDD 
comerciale o optimizare a execuţiei cererii. Metoda larg aplicată este reprezentată d 
optimizarea bazată pe cost care presupune următoarele: 

- selectarea tipului de acces la date (secvențial sau direct prin intermediul indecsilo: 

- selectarea ordinei în care vor fi executate operaţiile (de exemplu, ordinea in care Y% 
fi efectuate jonctiunile); 


294 


- alegerea unei opțiuni de execuţie atunci când sunt oferite mai multe astfel ce opcs: 
(de exemplu, alegerea metodei de joncțiune); 

- definirea locului din fluxul de prelucrare a execuţiei ordonării datelor atunci cà: 
cererea sau metoda de execuţie necesită ordonarea datelor. 

Majoritatea alegerilor şi optimizărilor cererilor distribuite sunt efectuate pe bez: 
ii costului total al execuţiei cu formula: 


Cina 7 Caro * jo + Cezu Tier + Ca the 


Cio — costul unei operaţii de VO; 
nio — numărul de operaţii de VO; 
Cceu— costul unei operații CPU (unitate centrală); 
nceu — numărul de operaţii CPU; 
Cy — cantitatea de date transmisă în rețea; 
n, — costul unitar de transmisie. 


10 „5. Controlul concurenţei 

DEC Incun sistem distribuito tranzacţie globală este descompusă în general in subtrenzacii 
săresate diverselor noduri. Considerând nivelul global sau cel local supervizorul execuj: 
zivelului trebuie să serializeze şi să planifice execuţia acestor tranzacţii, Pentru z elimiz: 
ientele generate de concurența care pot apare la execuţia tranzacţiilor atât tranzacţii 
adresate bazei de date globale şi cát şi subtranzacfiile pe care le generează trebuie să £e gloi 
serializabile. Serializabilitatea globală a tranzacţiilor distribuite peste nodurile unei baze de date 


produse la fiecare nod. 

^ Pentru rezolvarea conflictelor generate de concurență există diverse mecanisme și 

protocoale de asigurare a accesului concurent dintre care cele mai utilizate sunt meioda 

blocare în două faze (rwo-phase locking) și mecanismul de utilizare a mărcilor ie timp 

Atimestamping). 

Metoda de blocare în două faze are la bază următoarele principii : 

- nici-o cerere nu are acces la date dacă acestea nu au fost blocate in prealabil (biocate 
în citire sau actualizare); 

- după ce a blocat un element de date, acea cerere nu mai poate bloca nici-un alt 
element de date până nu deblochează elementul de date pe care la blocat. 


= 


$ Gestiunea blocării/deblocării (lock/unlock) înregistrărilor (obiectelor) poate fi zealizată 

„unul din modurile: 

* Centralizat: un singur nod are sarcina de a manipula cererile de blocare şi deblocare 

pentru toate obiectele; 

* Copie Primară: pentru fiecare obiect una din copii (replici) este desemnată drept copie 
primară iar toate cererile de blocare/deblocare ale acestui obiect sunt trarre de 

gestionarul blocărilor localizat în situl în care este memorată copia primară; 

Fiecare dintre aceste două moduri are dezavantaje cum ar fi, de exemplu. 

erabilitate la cădere în cazul gestiunii centralizate, sau dependență de copia primară care 

orice citire necesită comunicarea a două situri (copia primară si situl implicat). 

~ Total Distribuit: cererea de blocare/deblocare a copiei unui obiect memorar în situ 
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alai 
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este manipulată de gestionarul blocărilor/deblocărilor din situl în care este 
replica (copia). 


Fiecare bază de date locală (BDL,) poate fi exploatată local, de către utilizatorii locali 
(UL), prin intermediul sistemului de gestiune al bazei de date locale. 

Cererile de acces pot solicita date situate pe noduri diferite ale rețelei de 
Pentru a superviza execuţia unor astfel de cereri un nod trebuie să-și asume rolul de 
coordonator. Celelalte noduri, care concură la realizarea cererii, se numesc noduri cooperante, 
Un nod poate fi în același timp şi coordonator (pentru cererile lansate din acel nod) si 
cooperant (pentru cererile, lansate din celelalte noduri, care solicită acces la acest nod), 
Controlul execuţiei cererii la distanță se realizează prin schimb de mesaje (conform unui anumit 
protocol) între coordonatorul cererii si cooperantii acelei cereri. t 
Pentru asigurarea coerenjei, în caz de incident hardware sau software, se utilizează 
protocolul de "realizare in două faze” prin care execuţia fiecărei cereri de acmalizare este 
realizată în două faze: 


pregătirea execuţiei — în această fază are loc citirea datelor, scrierea în jurnalele 
locale a "imaginilor înainte” (date neactualizate) şi a "imaginilor după” (date 
actualizate); 
realizarea sau nerealizarea cererii — în acestă fază are loc introducerea actualizicilor 
în baza de date distribuită atunci când sistemul funcţionează corect, sau înlăturarea 
efectelor acestei cereri de actualizare la apariţia oricărui incident pe parcursul 
tentativei de realizare a ei. 
Cooperarea între noduri la realizarea cererii se efectuează conform următorului protocol. 
- nodul coordonator trimite mesajul PREGĂTEȘTE! (prepare) tuturor nodurilor - 
cooperante; E 
- fiecare nod cooperant realizează faza I-a (la primirea mesajului) și returnează 
nodului coordonator mesajul PREGĂTIT (yes); E 
- da primirea acestui mesaj, de la toate nodurile cooperante, nodul coordonator 
mesajul "REALIZEAZĂ! $ 


nodurile 
cooperante realizează faza a I-a. La 
incheierea cu succes a fazei a Il-a fiecare E 
nod cooperant transmite mesajul 
"REALIZAT (ack). 
Insuccesul realizării este anunțat prin mesajul X 
'ABORT lucru care duce la emiterea, de către nodul 
cooperant a mesajului 'REVENIRE' care declanșează 
procesul de refacere a bazelor de date la starea în care = 
se aflau înaintea lansării cererii. 
Acest mecanism garantează faptul că cererea Fig. 10.3 Utilizarea mărcilor de timp 
se execută corect peste tot sau nu se execută de loc. 1 
, Execuţia cererilor, in ordinea emiterii lor 
(serială), la toate nodurile cooperante este asigurată 
- mărcile de timp; 
= inelul virtual. 


Marcile de timp (figura 103). La emiterea ei, fiecare cerere, primeşte în mod autonal 
marcă de timp (identificatorul nodului plus timpul ceasului local). Fiecare articol din baza 
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Baze de date distribuite 


timp a cererii care a actualizat-o. Sistemul 
gestiune asigură execuţia cererilor în ordinea 


AL a 


Fig. 10.4 Utilizarea mecanismului de 
“inel virtual" 


unică în reţea; 

Inelul virtual (figura 10,4). Nodurile 
rețelei sunt înlănțuite logic, formând un inel 
virtual, în care fiecare nod are un predecesor şi succesor binc stabilit, Pe acest inel circulă 
continuu un tichet. Inelul poate fi văzut ca o rejea circulară de cale ferată pe care circulă 
“vagoane”. Un vagon poate fi ocupat, dacă este liber, cu ajutorul rezervării sale prin 
completarea "tichetului”(biletului) de închiriere. Acest vagon are, deci un furnizor care îl 
angajează şi încarcă şi un destinatar, care în mod normal il descarcă. Este posibil ca destinatarul 
să lipsească, de aceea, eliberarea efectivă se va efectua în momentul în care vagonul reapare la 
fumizorul care la încărcat, 

Nodul la care se afla tichetul, dacă acesta este liber, poate să emită un mesaj. Tichetul 
trece apoi pe la toate nodurile iar mesajul este preluat de nodul căruia îi este adresat (nodurile 
cooperante). Când tichetul ajunge din nou la nodul care a emis mesajul acesta devine liber si 
pleacă la nodul următor. 


10.1.6. Dicţionarul (catalogul) Sistemului Distribuit 


Utilizatorii dicționarului sistemului distribuit (DSD), ca element de bază al arhitecturii 


- utilizatorii BDD (orice cerere de acces). 

În schema din fig. 10.5 sunt evidenţiate funcțiunile specifice ale DSD pentru fiecare 
gamă de utilizatori. 

Pentru utilizatorii BDD orice cerere de acces la baza de date distribuită (exprimată în 
limbaj ional de la terminale "on-line", staţii de lucru sau prin programe de aplicaţie 
scrise în limbaj de nivel înalt) parcurge următorii paşi: 

- analiza tranzacţiei prin: 

e control sintactic efectuat la cel mai înalt nivel al LMD; 
. tranzacţiilor complexe în tranzacții simple; 

- translatarea cererilor: 

. precompilarea (pentru cereri exprimate cu ajutorul limbajelor de nivel înalt) sau 
interpretarea în scopul obținerii unui set de instrucțiuni exprimat în limbajul 
intern al SGBDD; 


© utilizarea dictionarelor de corespondență 
ca e cores pentru a transforma cereri 
< în cereri simple (structuri de fisiere, mod de realizare a distribuirii fizice etc) 
includerea apelurilor la metodele de acces disponibile, în cererea tradusă; 
funcţia de translatare are rolul de a identifica limbajul țintă (limbajul utilizat c 
către SGBD-ul local căreia îi este destinată fiecare parte a cererii). * 


1 


Figura 10.5 Funcţiunile oferite de DSD 


Fig. 10.6. DSD - interfaţă a rețelei 


- controlul accesului: 


e asigurarea consistenței bazei de date (verificarea corectitudinii 
verificarea accesului concurent, verificarea drepturilor de acces, far 
, de date în cazul funcționării prac pes jore 
distribuire: 
* optimizarea distribuției cererilor conform unor criterii predefinite (adi 
d x as ite (adică să 
separe "local! ale ef Dic dali dote d ea rade 
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execuție a cererilor elementare, să aleagă ruta optimă în scopul optimizării 
anumitor factori ca timp de acces, 
timp de prelucrare, trafic în rejea 
etc). 


Descompunerea tranzacţiilor solicită ca DSD 
TS conțină informati despre date (de exemplu, cum. 
îm fi localizare, accesibilitate, disponibilitate, 
“proprietăţi statistice etc). 

£ Proiectanţii de sistem informatic utilizează 


So pentru a afla informaţii despre: 

T — evaluarea performanțelor (conform 

E] componentelor software / hardware, 

3 diferitelor arhitecturi etc); 

m - simularea unor metode de acces pentru 
selectarea celor cu performante ridicate; 


á - modul de efectuare a conversiilor de 
$ Prud" fişierelor destinate  stochrü Fig, 10.7. Arhitectura logică a DSD 
elor bazei de date globale. 
Administratorii de sistem pot obține informaţii despre: 
- schema conceptuală a reţelei de calculatoare (administrare reţea); 
- schema externă globală pentru toate aplicaţiile care utilizează BDD (administrare 
aplicaţie globală); 
- administrare locală BD similar modului de efectuare a administrării bazelor de date 
centralizate, 
Funcţiile de interfață ale DSD cu reţeaua (figura 10.6), utilizatorii si programatorii sunt: 
- generarea automată a macroinstrucțiunilor de interfaţă cu diversele SO (sisteme de 
operare) gazdă; ——Ó: 
- apelul automat al compilatoarelor limbajului de manipulare a datelor (LMD); 
I. generarea automată a macroinstruciiunilor, pentru diversele metode de acces, cu 
ajutorul unui catalog al nodurilor, numelor si metodelor de acces la. datele locale; 
- interfee, prin mijlocirea "mapărilor de corespondență” (dicţionare) între diversele 
lc de transmisie. 
Cererile utilizatorilor sunt descompuse in cereri simple cu ajutorul DSD in conexiune cu 
SGBDD iar DSD coordonează distribuţia şi execuţia, cererilor în rețea, în conexiune cu NOS 
(sistemul de operare al rețelei). 
Pentru realizarea acestor funcţii DSD trebuie să ofere informaţii despre: 
- localizarea datelor (nume fişiere, nodul de stocare, criteriul de fragmentare, copii, 


etc); 
- structura datelor (numele şi formatul atributelor, date statistice, cardinalitatea 
fişierelor, etc); 
- disponibilitatea datelor; 
=. utilizarea datelor. 
În arhitectura logică prezentată în figura 10.7, sunt evidenţiate dicționarele logice pe 
- care le poate conține DSD. În această schema dicționarele logice globale evidenţiate pot face, 
L ele însăşi, obiectul distribuţiei (pot fi distribuite). 
general acest DSD se prezintă, practic, ca o bază de date relational in care tabelele 
componente reprezintă unul din tipurile de dicţionare logice evidenţiate. 


299 


Ei 


Capitolull0 


10.2. Niveluri de organizare H 
Nivelurile de organizare a datelor sunt determinate de modul de structurare a SGBDD 
conform nodului ilustrat în figura 10.8. $ 
- Nivel extern reprezintă totul sau o parte a BDD așa cum este văzută de un utilizator 
particular sau de către un ansamblu de programe de prelucrare. * 
- Nivel conceptual global descrie ansamblul informaţiilor care constituie BD fără să 
se țină cont de aplicaţii si de reprezentarea fizică a datelor. 1 

- Nivel local reprezintă o viziune omogenă asupra bazelor de date locale. 


Fig. 10.8. Structura unui SGBDD 


10.3. Interacțiunea utilizatorilor cu baze de date 
distribuite 


10.3.1. Baze de Date Locale - Viziuni locale 


lodelul definit pentra descrierea viziunilor locale trebuie să permită sati: 
restricțiilor legate de descrierea bazelor de date locale cât şi de utilizarea acestor descrieri 
vederea unor cooperări exprimate în descrierea viziunii globale (de exemplu, 
restricțiilor de integritate generate de viziunea globală). 

Descrierea viziunii locale comportă două părți : 


Baze de date distribuite 


- descrierea relațiilor care caracterizează obiectele bazei de date locale. Această 
descriere ridică problema controlului/menținerii coerenfei BDL "clasice" (exprimată, 
în modelul relaţional, prin restricții de integritate a datelor enunțate sub formă de 
predicate). 

- descrierea operaţiilor de manipulare disponibile pe aceste relaţii. Acestea se vor 
exprima sub formă de programe locale direct interpretabile de SGBD-ul local 
realizând cooperarea între viziunea locală si BD locală. 

Determinarea programelor locale și a conţinutului lor poate fi efectuată: 

- prin decizia administratului BD globale sau administratorului BD locale; 

- prin construcţia lor mai mult sau mai puţin automată plecând de la caracteristicile 
entităţilor (relaţiilor) şi schemele bazelor de date locale. 


10.3.2. Baza de date globală - Viziuni globale 


Scopul unui SGBDD este acela de a pune la dispoziția utilizatorilor datele (sub forma de 
baze de date locale) aflate sub controlul mai multor SGBD-uri (eventual de diverse tipuri). 
Scopul viziuni globale este acela de a asigura transparență acestei repartifii. Vi 
descriu legăturile dintre bazele de date locale în funcţie de obiectele acestor 

Proiectantul unci baze de date distribuite trebuie să : 

- aleagă un model de descriere a viziunii globale; 

- aleagă un model de exprimare a corespondenjelor între obiectele viziunii globale și 
obiectele viziunii locale; 

- ofereo soluţie prin care repartiția şi cooperarea nu sunt definitive. 

Proiectarea BDD este un proces complex. Stadiile care trebuiesc parcurse ar fi: 

- proiectarea schemei globale similar ca la o BD centralizată; 

- proiectarea schemei unei BDL; 

- proiectare schemei de alocare (localizare); 

- proiectarea schemei de replicare. 

Atunci când se ajunge la stadiul de proiectare a schemei de replicare proiectantul are 
deja un sistem care poate lucra fără replicare, Se pune întrebarea atunci, de ce replicare? Există 
tei motive speciale: 

- capacitatea mai mare a sistemului (disponibilitatea) vis-a-vis de căderi ceea ce 
implică o funcţionalitate sporită, îmbunătăţind performanța cererilor care solicită 
suport mai mare de salvare a informaţiilor; 

- pentru a mări disponibilitatea datelor şi performanțele BDD se acceptă în anumite 
cazuri replicarea datelor; 

- memorarea de copii multiple ale acelorași date pe mai multe calculatoare (în 
general, se justifică existența unei copii numai dacă costul menținerii ei - memorare 
+ actualizare + acces - este mai mic decât costul acceselor la distanţă pentru a 
obține acele date). 

Modelul de descriere a viziuni globale ales trebuie să permită considerarea acestei 

Viziuni globale ca o viziune locală pentru o noua descriere. 

Descrierea unei viziuni globale se compune din elementele: 

- Descrierea structurii datelor globale: descrierea relaţiilor globale şi a restricțiilor de 
integritate globale conform viziunii ansamblului aplicaţiilor, Cu aceste obiecte se 
vor exprima cererile utilizatorilor globali. Modelul de descriere al viziunii globale 
trebuite să satisfacă următoarele exigențe : 


————— 


* să permită descrierea relațiilor globale si a cererilor utilizatorilor care solicită 
aceste relaţii, 

* să permită exprimarea corespondenței global-local ştiind că viziunile sunt 
exprimate sub formă de relaţii şi programe locale; 

LI NUNC MEINE. GRON Kup wec vies a 


. ACRES tei RE pla Pa în fapt acesta încorporează 
legăturile dintre schemele implicate şi datele de localizare. De asemenea trebuie să 
permită cunoașterea numelui relațiilor locale şi a operaţiilor disponibile pe acestea 
pentru a permite descompunerea si apoi optimizarea cererilor globale. 


10.4. Criterii 


Fie B o bază de date distribuită si P; P:, ..., P; părțile care o compun. Modul în care 
informaţiile sunt distribuite pe diferite baze se bazează pe următoarele două noțiuni : 
- Partiţionarea (sau decuparea în ansambluri disjuncte): 
Dacă o Bază de Date Distribuită (BDD ) B este partiționată, aceasta înseamnă că 
părțile P1, P2, ...., Pj care o compun formează subansambluri disjuncte: 
B= (PIUP:U..UP,] cu { Pirin. OP) 0 
- Replicarea (Duplicarea) sau crearea a mai multor copii ale aceleiași informaţii. Are 
ca scop mărirea disponibilităţii datelor (dacă un fragment "cade"replica sa fi poate 
lua locul) şi mărirea vitezei de evaluare a cererii (cererile pot fi executate mai rapid 
prin acces la copii locale şi nu în nodurile aflate la distanţă). 
Duplicarea/replicarea (menţinerea unei copii de fragment) se justifică (din punci de 
vedere economic) numai dacă se menţine inecuajia: ———— 


Cme+ $ Cal, + Ca <$ Cad, 
3 c 


de Distribuire a Datelor 


u — numărul de utilizatori ai copiei; 
Cme - costul de memorare (stocare) a copiei; 


Cad,— anipe ooo ERE POETI 
Gestiunea copiilor multiple este în sarcina SGBDD iar actualizarea acestora se poate 
realiza în două moduri : 
- simultan cu actualizarea bazei de originale (replicare sincronă); 
- actualizarea copiei primare şi aducerea la zi a copiilor secundare cu o anumită 
întârziere (replicare asincronă). 
O bază de date distribuită B replicată poate fi: 
- total replicată, aceasta înseamnă că diversele baze de date locale sunt copii 3 
aceleaşi baze, adică: B= P,7P; =....= Pj. 
- parțial replicată, aceasta înseamnă cà aceeaşi informaţie se poate regăsi în mai mul! 
de o bază de date locală: 3i, j astfel încât Pin Pje O 
Pentru exemplificarea acestei noțiuni vom considera o bază de date B a cărei schem 
relational& globală R este următoarea: R< NE.NP,LOC,PRET,CANT> reprezentată pe tupli 
(în extensie) în figura 10.9. Un tuplu «f,p.o,lia? eR dacă și numai, dacă: "fabrica numiri f 


302 


ausw e 


Fig. 10.9. O realizare a lui R avind 6 tupli 


că baza de date B este distribuită pe trei no3— Ni BE 


- nepartiționată: aceasta înseamnă că porțiunile F 
A R<NE.NP.LOC PRET.CANT>. Í sase 


că schema este replicat şi putem avea următoarele cezuzi 2s scc ines 
sale (obiectelor): 
e partiţionarea obiectelor: (decupaj orizontal) în sxs zt ase móe à c 
decupare orizontală a tabelei R, de exemplu: 
NI  cutuplurile 123 
N2  cutuplurile 4,5 
N3  cutuplul 6 


e replicarea obiectelor: 
o replicare totală: extensia tabelei R se regässșs 2e ze 


N2, N3; 

o replicare parțială, de exemplu: 
NI cutuplurile 12346 
N2  cutuplurile 45 
N3  cutplurile 2,6 


- schema partifionatà (decupaj vertical): 


Vom considera decuparea relației R în trei sub-relați Ri, 7 

RARR). 

4 Deci R este compunerea relaţiilor care pot avea următoarele schans is sammi 
RNE LOC) RANP.PRET) R:NENP CA 

În aceste condiții putem opta pentru următoarele cazuri de realizare 2 2:75:75 

© partifionarea fără replicare a cărei modalitate de producers poze 5 erem“ 5smt 


h 
= 
4 
* 
R 
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N2 > Ra 

N3 — RiRa R3 h 

Cel mai bun exemplu de replicare este reprezentat de sistemele suport pentru decizie - 

care trebuie să colecteze date aflate in diverse noduri pentru a determina diveryii indicatori 

necesari analizei. Pentru a mări eficienţa acestor tipuri de prelucrări de regulă se realizează o 

copie locală a datelor necesare (o replică) în colecții denumite “data warehousing” (depozit de 

date). Diferența reprezentată de depozitul de date față de baze de date distribuite este dată de 

faptul că datele nu trebuie să fie neapărat baze de date. Ele pot fi reprezentate şi de diverse 
tipuri de fişiere disponibile via sisteme de operare, a căror replică este inclusă. 


10.4.1. Criterii de alegere a distribuţiei 


Ca şi la baze de date clasice există două moduri distincte de abordare a concepției BDD; 
- descendentă, care corespunde celei mai bune distribuiri (figura 10.10.); £ 
~ ascendentă, care corespunde celei mai bune cooperări (figura 10.11.). t 
Aceste moduri independente nu exclud abordarea mixtă. 
Abordarea descendentă. Dacă presupunem că BDD este creată cu toate piesele sale 
componente atunci activitățile de concepție şi punere a sa în lucru sunt similare celor de BD 
centralizate, exceptând problemele legate de distribuirea datelor în noduri. La acest mod de 
abordare poate fi controlat nivelul redundajei pe care dorim să o introducem luând decizia 
asupra datelor care vor fi duplicate. Pentru efectuarea duplicarii și decupării (fragmentării) 
trebuie să ținem cont de natura prelucrărilor şi volumul informaţiilor manipulate pe fiecare 
prelucrare şi de asemenea de gradul de fiabilitate pe care dorim să-l obținem. 3 
Abordare ascendentă. Această abordare presupune existența mai multor baze de date 
locale (BDL) implementate și exploatate sub SGBD. Reutilizarea acestor baze de date poate fi 
efectuată prin : 
- integrarea bazelor de date după modificări: în această ipostază se restructurează 
BDL pentru a se adapta noilor aplicaţii. 

- integrare BDL fără modificări: în această ipoteză se vor utiliza BDL fără a le 
modifica structura. Cea mai dificilă problemă este cea legată de integrarea bazelor 
de date eterogene. : 


10.4.2. Construirea bazei de date distribuite 

Modul de construire a unei baze de date distribuite este dependent de tipul abordarii. 

Abordarea descendentă. Considerăm relaţia globală : SALARIAT(MARCA, NUME, 
VIRSTA, SALARIU, LM, SEF) care descrie pentru fiecare SALARIAT identificat prin marca. 
(MARCA), numele (NUME), vârstă (VIRSTA), salariul obținut (SALARIU), locul de muncă 
(LM) şi seful ierarhic (SEF construit pe același domeniu cu MARCA). 1 

O posibilitate de distribuire o constituie decuparea ei în trei fragmente F1, F2, F3 (figură 
10.10.). Această descompunere este de fapt o partiționare fără duplicare care permite un control 
total al repartiției în măsura în care fiecare dintre fragmente este stocat într-o bază de date 
locală. 
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Baze de date distribuite 


Marca Nro Tari Lm Sel 
7 Tm 


(() SAL- NRO'TARIF 


Proiectarea structurii globale: (^*) Valori Nedefinite 


abordarea ascendenta 
Relstile Locale R}, Rg Rasint integrate in relatis 
Giobala R, [n relatia globale nu mai apar atributele 
vizate pentru calculul valen atributului SAL. 


Fig. 10.10. Abordarea Ascendentă 


Proiectarea sueri bazei de date distribuite: 
abordarea decendenta 


Relatie Globala A este descompusa p 
- decupaj orizontal în relatiile R 9i Rg 
si 


-decupaj vertical in relata R} * 


Fig. 10.11. Abordarea Descendentă 


ans 


Abordarea ascendentă. Punctul de plecare fi reprezentat, de exemph i 
telafi RI, R2 şi R3 (figura 10.11.) cu umätonrele scheme: Z SEN 
RI(MARCA, NUME, VIRSTA) 
RI(MARCA, NUME, VIRSTA) 
4 ; R3(MARCA,NRO, TARIF, LM, SEF) 
cu fiecare relație stocată într-o bază de date locală, dar privind salariaţii care aparțin aceleiași 
societăți. Plecând de la aceste relații vom defini relația globală cu schema: eos 
SALARIAT (MARCA, NUME, VIRSTA, SALARIU, LM, SEF) 


Atributele relaţiei SALARIAT sunt reprezentate de: 

~ atribute existente în R1, R2 si R3:MARCA,NUME,VIRSTA,LM,SEF; 

=. atribute care corespund unor valori calculate plecând de la cele existente in R1, R2 și 
R3: SALARIU ca produs NRO*TARIF. 


10.5. Criterii de localizare si regásire a datelor 


Elementele rezultate din activitatea de fragmentare sí replicare sunt pl; liferi 
x l plasate pe diferite 
noduri ale rețelei de calculatoare. Eementele de date plasate pe un nod al reţelei cena o 
bază de date locală. Sistemul asigură transparența localizării şi autonomia noduluă (a BDL 
stocată în nod). 

În cazul distribuţiei trebuie respectată convenția de unicitate a numelor (a obiectelor în 
cadrul unei BDL si a numelor nodurilor BDL). Sinonimele si viziunile (vederile) permit 
utilizatorilor să acceseze orice obiect din BDD folosind aceeași sintaxă ca la accesarea 
obiectelor din propria instanţă a BDL. 

Transparenţa localizării se referă la faptul că sistemul BDD ascunde fașă de utilizatori 
localizarea reală a datelor. Utilizatorii trebuie să cunoască numai numele obiectelor BDD si si 
aibă privilegiile necesare pentru a le accesa cu funcţiile solicitate. Principalele avantaje ale 
transparenţei localizării sunt: 

~ utilizatorul nu trebuie să reţină sau să-și reaminteascá unde sunt localizate datele și 

obiectele; 

- BDD (tabelele) pot fi mutate între BDL fără nici-un impact asupra utilizatorilor sau 

aplicaţiilor lor. 

Autonomia BDL se referă la faptul că fiecare BDL parte a unei BDD este administrată 
separat şi independent de celelalte BDL. Avantajele autonomiei sunt: 

- 0 mai bună rezistență la incidente; 

- BDL este disponibilă pentru toţi utilizatorii atâta timp cât BDL şi rețeaua de 

calculatoare este disponibilă 

- nu există un punct central a cărui defectare opreşte toate operaţiile cu BDD; 

- fiecare nod îşi continuă activitatea locală dacă rețeaua a căzut; 

=. refacerea după căderi este locală; 

- control local; 

- dicționar de date pentru fiecare BDL; 

- nodurile pot face actualizarea software-ului (upgrade software) independent. 
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Schimbările la o BDL afectează numai acea BDL si trebuie să fie validate doar de ea. În 
context domeniul de ilitate al ABD este mic şi uşor de controlat. În cadrul unei 
JD bazele de date locale (BDL) sunt egale si au responsabilități egale. 


051. Cazuri de distribuţie 


H Considerăm mulţimea A = ( aj, az...» ap} ale cărei elemente sunt tupluri şi o mulțime C 
"de q calculatoare, C = ( C), Ca... Ca). 
zx Fiecare. calculator este capabil să stocheze totul sau o parte a lui A. Legătura 
T caracteristică între A şi C se poate exprima cu ajutorul unei funcţii de localizare "Ioc(": 
4—m c 
Vom examina diversele cazuri de distribuire prin prisma naturii funcţiei de localizare. 
“Vom numi schema de alocare schema care descrie maparea completă a relaţiilor sau 
“fragmentelor lor pe serverele care le stochează şi care permite transferul de la o descriere logică 
"lao descriere fizică a datelor. Maparea poate fi: 
= non-redundantă, atunci când fiecare fragment (sau relaţie) este alocat(8) unui singur 
nod; 
-  redundantà, atunci când un fragment (sau relație) este alocat în două sau mai multe 
noduri. 

Fiind date mulțimea de elemente A şi mulțimea de calculatoare C vom numi grad de 
distribuţie a lui A (notat gradis(4)) numărul de calculatoare care conțin elemente ale lui A. 
. Muljimea A considerată este o mulţime globală şi în acest caz elementele sale se 
situează la nivel global. : 

Cu aceste precizări avem următoarele cazuri de distribuţie: 
A distribuție trivialà (gradis(4) 1). Mulțimea A este stocată in totalitatea sa pe un 
5 singur calculator. În acest caz mulţimea globală şi mulțimea locală coincid. 

- partijionare (gradis(4)S q). Mulțimea A este decupată în submuljimi disjuncte, 

fiecare fiind afectată unui singur calculator și numai unuia. Mulțimea globală este 

" reuniunea tuturor mulțimilor locale. 
replicare totală (gradis(4)= q. Mulțimea A este copiată pe fiecare calculator. 
z Mulțimea globală este una din mulțimile locale. 

~ partiţionare cu replicare (1 < gradis(A) <a). Mulțimea A este descompusă si parţial 

replicată (duplicată) pe mai multe calculatoare. În același timp există un ansamblu C" 


b c C de calculatoare astfel încât reuniunea elementelor pe care le conţin formează 
mulţimea 4. 
= element calculat (gradis(4)-O). Nu există nici un calculator care contine elemente 
E ale lui A. În acest caz elementele respective se obțin prin calcul, pornind de la 
i elementele care sunt, la rândul lor stocate pe unul sau mai multe calculatoare (de 


exemplu SALARIU = NRO*TARIF). 


10.5.2. Criterii de distribuire şi localizare a elementelor 
$ Un element al lui A este nedecompozabil în raport cu distribuirea dacă este stocat în 


htregime pe un singur calculator. În condițiile existenței unui mediu distribuit putem avea 
următoarea clasificare a distribuirii şi localizării bazelor de date locale: 
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corespondenţă directă cu un nume de calculator (si numai unul) care confine toate 
elementele lui A. i 

~ distribuție prin restricție şi localizare directă. Submultimile disjuncte ale lui A sun 
determinate ca restricții ale acestei mulţimi. Restricţia se aplică pe valorile care 
compun elementele lui A. Luând ca exemplu relația SALARIAT descrisă anterior, 
im cec de pertinere pe douk calculatie C, şi Ca ar putea fi efectuat pe 

lariu: 
* pe Ci vom avea schema SALARIAT care va admite numai tuplurile bazei de 
date care îndeplinesc condiția (SALARIU < 1500 ); 
* pe Cz vom avea schema SALARIAT care va 
îndeplinesc condiţia (SALARIU >1500). 
Fiecare restricție este o expresie predicativă şi în cazul unei partiţionări aceste 
expresii trebuie să fie disjunctive. Acest tip de localizare este direct deoarece una 
sau mai multe valori ale unui obiect permit obținerea directă a calculatorului unde se 
află (se va afla) acest obiect. 

-  partiţionarea prin vecinătate şi localizare tranzitivà Amplasarea unui element 

depinde de cea a altuia (de exemplu repartizarea salariaţilor în baza de date a unei 
societăţi cu mai multe întreprinderi se face în locul unde figurează întreprinderea la 
care sunt angajaţi). 
La nivelul unui element a= (a;,az, ..... ap) există un subobiect compus a'= (ap ax-4, 
ze de) al lui a astfel încât Ay X Axei X... X Ax reprezintă de fapt cheia, 
localizarea lui a reducându-se la localizarea lui a’. Pentru acest gen de localizare ne 
vom limita la o tranzitivitate de nivel 1 care semnifică faptul că dacă o relaţie R este 
vecina unei relaţii S, aceasta din urmă nu poate fi definită, ca însăşi, prin vecinătate 
cu altă relaţie. 

- partifionarea cu licarea prin restricţie. Fiecare restricţie corespunde unei 
expresii predicative. În cazul unei partiţionări aceste expresii trebuie să fic disjuncte. 
Dacă expresiile nu sunt disjuncte (total) atunci se realizează o decupare care va 
antrena duplicări dar va permite o localizare directă prin valoarea unui obiect 
(permite obţinerea directă a calculatorului pe care se află/se va afla acest obiect). 

De exemplu, dacă avem distribuţia: pe Ci relația SALARIAT cu restricții 
800<-SALARIU<>=1500 atunci salariaţii cu salariul cuprins între (800, 1500] vor 
avea datele stocate pe calculatoarele C; $i Ca. * 

- duplicare totală şi localizare directă. Se consideră ca A este total duplicat peo. 
mulţime de calculatoare Ck, Cksi, -.., Crp. Localizarea unui element al lui A este — 
rates aea se dere NE 


numai tuplurile care 


cerute. 

- partiționarea arbritrară, localizare calculată. — În acest caz nu există un criteriu - 
explicit de partilionare care să se poată descrie printr-o expresie predicativă sau prin 
vecinătate. Este necesară utilizarea unor funcții de localizare calculată care depind - 
de criterii proprii. Acest calcul trebuie să poată fi exprimat cu ajutorul unor reguli - 
globale explicite. 5 


10. 


Optimizarea performanţelor 


Întroducerea redundanjei (prin duplicar) într-un sistem distribuit este un 
fundamental pentru optimizarea performanțelor. Redundanța are ca efect : 
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distribuție triviald şi criterii de localizare directă. Numele mulţimii este în 


Baze de date distribuite 


- o mai mare disponibilitate a datelor (o cădere a unui nod nu afectează prelucrarea în 
sensul că cererile adresate acestuia vor fi redirectate către nodul care conține copia); 
- o ameliorare a tipurilor de răspuns prin căutarea informaţiilor în nodul cel mai 


apropiat; 

- o diminuare a încărcării SGBDD (mai multe copii în diverse noduri permite 
descongestionarea nodului care ar fi conţinut informaţia căutată). 

Dezavantajele principale ale utilizării redundanfei se referă la: 

- asigurarea cocrentei diverselor copii; 

- problema costului de stocare, 

În cazul introducerii redundanței avem următoarele soluţii posibile pentru duplicare: 

- totală: dacă BDD este duplicată în toate nodurile orice cerere poate fi executată în 
întregime pe un singur nod, deci se reduce la execuția locală la un nod. Avantajul 
acestei soluţii este că avem performanțe foarte bune dar cu inconvenientul de avea 
prea multe duplicări care pun probleme de actualizare şi de capacitate de stocare. 

- pe regiuni geografice: BDD este total duplicată pe o regiune geografică (un 
ansamblu de noduri). Regionalizarea permite limitarea la o singură regiune a 
prelucrării cererii cu avantajul de a avea foarte bune performanţe fără a avea foarte 
multe copii; 

- mixtă şi alocarea copiilor în apropierea nodului utilizatorului avem cazurile : 

* duplicare totală; 

© duplicare pe regiuni geografice; 

* duplicare pe subansambluri de regiuni geografice; 
e absența a duplicărilor. 

O schemă de optimizare a prelucrărilor distribuite a cererilor maximizând performanțele 
gi minimizând duplicările se realizează parcurgând etapele : 

- apropierea: căutarea, printre realizările posibile, a realizării optime care are o 

"suprafaţă logică” minimală cu utilizarea duplicărilor; 

- maximizarea prelucrărilor locale şi filtraj al relaţiilor locale inutile pentru criteriul de 
distribuţie; 

- căutarea unui "baricentru" de execuţie: găsirea unui nod unde trebuiesc transferate 
rezultatele prelucrărilor locale şi unde vor fi executate prelucrările globale pentru 
obţinerea unei execuţii globale optimale. 

O metodă de alocare a copiilor în vederea maximizării performanțelor este "cel puţin o 

copie pe o arie logică. 

O arie logică poate fi definită ca un ansamblu de regiuni care sunt apropiate unele faţă 
de altele la nivelul distanței logice. Distanţa logică este definită ca timpul de transmisie a unei 
entităţi de informaţie între două noduri. 

Pentru relaţiile globale care sunt distribuite în întreaga reţea se fac duplicări pentru a 
avea cel puţin o realizare a fiecărei relații globale în fiecare regiune logică. 

Pentru relațiile globale care sunt distribuite într-o regiune geografică, sau într-un nod, se 
poate evita efectuarea de noi duplicări graţie apropierii şi determinării baricentrului. 

La acest nivel o relaţie globala (RG) poate fi extrasă dintr-un ansamblu de noduri si 
caracterizată de o frecvenţă de utilizare numită "utilizare": 

RG = ((noduri), utilizare) 
Pentru utilizare vom distinge două cazuri : 
im": RG este utilizata foarte des; 
- "normal": RG nu este utilizata foarte des. 
Suprafaţa logică (sl) a fiecărei relaţii globale poate fi definită ca: 
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sl 5 DL, , unde DL, este distanța logic a unei aiti de informatie intre doză sod 
LN 


şi], cui, i e (noduri) ale unei RG date. 
Vom defini prin k media distanțelor logice pentru o regiune geografică. 
În funcţie de valoarea Iui sl se poate decide efectuarea efectuarea duplicărilor pentru fiecare relație 
globală, conform cu urmätoral 
sio, RG distribuită pe un nod. Se vor efectua copii numai în cazul unei utilizări 


maxime; 
- dek RG este distribuită pe o regiune geografică. Se vor efectua copii numai în 
cazul unei utilizări "maxime" 
- sl > k, RG este distribuită în toată rețeaua. Duplicarea nu mai depinde de tipu 
- dacă a este limita maximă a si a unei realizări atunci este necesar să facem duplicări 
dacă sl >= a si si conţine mai mult de o regiune logică. 
Dacă k=< a <= si a unei regiuni logice, atunci fiecare RG pentru care si>k trebuie să 
aibă cel puţin propria să realizare in fiecare regiune logică şi suprafaţa logică a fiecărei realizări 
posibile trebuie să fie inferioară lui a. 


10.6. Implementarea distribuţiei în SGBDD 
comerciale 


10.6.1. Implementarea distribuţiei în Oracle 


Un sistem de baze de date distribuite (figura 10.12) permite aplicaţiilor accesul la datele 
din baze de date locale si baze de date aflate la distanță (remote databases). Setul de baze de 
date inclus în sistemul distribuit apare utilizatorului ca o singură sursă de date, Oracle distribuit 
utilizează şi o arhitectură de proces distribuit. Procesarea cererilor adresate bazelor de dzie 
distribuite Oracle este realizată prin utilizarea unei arhitecturi client/server (serverul este 
software-ul care gestionează baza de date iar clientul este aplicaţia care cere informaţii de l2 
server), 

Figura 10.12 ilustrează un sistem de baze de date distribuite Oracle în care sunt 
implicate două baze de date localizate pe servere separate: HQ și Sales. Comunicaţia între 
servere este asigurată de Oracle Net iar clientul poate realiza o conectare direc 
(CONNECTED TO...) sau indirectă (IDENTIFIED BY...). Cererile sunt adresate direct bazei 
06 Pim entalpie Bala i acte tt onc 
un client). 
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uerxr nuo megeaies. .; 
DELETE OH DNI. 

TEM Beas + 
Cow; 


Fig. 10.12 Un sistem de baze de date distribuite 


— Heterogenous Services, o componentă a sa, in conjuncfie cu un agent (transparent gateway), 
ENI Mau d de in Orale sepoi ODDC Holen Sani ODBC) su proiocoale 
DB (Heterogenous Sevices OLE DB agent) se poate utiliza conectivitatea generică pentru, 


la date, ceea ce reduce costul în cazul în care este necesară achiziția unui agent specific 


„„ de acces la date. Fiecare bază de date care participă la o bază de date distribuită este ideziiicată 
în mod unic prin numele bazei de date globale: numele este format prin prefixarea urme i sau 
_(DB_NAME) cu numele domeniului rețea al bazei de date (specificat de DB. DOMAIN), 
conform modului ilustrat în figura 10.13. 

Numele bazei de date este format pomind de la o frunză în arbore și urcând spre 
“rădăcină. De exemplu Finance este în Division] din ACME_ TOOLS din domeniul com, adici: 
T finance divisionl.acme tools.com. Dacă mai multe baze de date pot avea același nure local 


numele global trebuie să fie unic. De exemplu, numele HQ este utilizat pentru două baze de 


date locale, numele lor global fiind: 
hq.divisionl.acme tools.com 
hq.us.americas.acme. auto.com 


rm 


«e 


_ Europa si Sales la diviziunea America astfel: 
sales.uk europe.acme_auto. com 
sales.us.americas.acme_auto.com 


y 


— 


MM s M dE 
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[ovson: 


Fig. 10.13. Aranjarea ierarhică a bazelor de date în rejea a 


Replicarea datelor. Un obiect replicat este un obiect al bazei de date care există pi 
multiple servere într-un sistem de baze de date distribuite. Intr-un mediu replicat o 
actualizări ale unui obiect replicat la un situ sunt aplicate la toate copiile la toate celelate situri. 
Dacă Oracle? avea două facilități pentru a suporta._replicarea datelor, snapshot si trigger-ele, 
Oracle$i permite replicarea (advanced replication) următoarelor tipuri de obiecte: tabele, 
indecsi, vederi şi obiecte vederi, pachete si corp de pachete, proceduri şi funcţii, tipuri de date 
definite de utilizator şi corpuri tip, trigger-e, sinonime, indecsi tip si operatori definiji de 
utilizator. Mai mult la replicarea tabelelor sunt suportate facilităţi avansate ca tabele partifionate,- 
tabele organizate ca indecşi, tabele conținând coloane cu tipul de dată definit de utilizator şi 
obiecte tabele. 

Cereri distribuite. În cadrul unei BDD pot fi emise două tipuri de cereri: 

* cereri locale - cereri care se adreseaza unei singure BDL; 

-~ cereri distribuite - cereri care solicită date localizate în mai multe BDL. [= 
Din punct de vedere al utilizatorului nu există nici-o deosebire între cele douk, 
(transparenţa localizării); deosebirea există doar în modul in care sistemul de BDD tratează 
cele două tipuri de cereri. Cererea distribuită permite: 
- referirea de date din mai multe BDL; 
- efectuarea de joncţiuni şi cereri imbricate pe tabele situate pe noduri diferite; 
~ definirea de viziuni peste tabele localizate în BDL diferite. A, 
Oracle permite utilizarea în context distribuit a următoarelor comenzi ale limbajului 


(nealocată în sistemele eterogene) si lock table. 

Rolul clienţilor şi serverelor. Un sistem de BDD este alcătuit din clienți si servere. 
calculator poate fi numai client (dacă nu are o BDL localizată pe el), numai server (dacă 
localizată o BDL pe el) sau şi client şi server (dacă are localizată o BDL pe el şi dacă pe el 
execută si aplicaţii client). Sistemul de BDD necesită ca legăturile între BDL-urile care 
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BDD să fie prestabilite. Ele se realizează cu ajutorul comenzii SQL CREATE DATABASE 
LINK. Clientul este responsabil pentru execuţia aplicaţiei, El transmite comenzile SQL ale 
aplicației la serverele care realizează funcţiile lor. Serverele analizează şi execută aceste 
comenzi şi transmit răspunsul şi/sau codul de retur la client. 

Legăturile bază de date. Conceptul central al sistemelor de baze de date distribuite 
este legătura bază de date (database link), care este o conexiune între două servere de baze de 
date fizice care permite clienților să o acceseze ca pe o bază de date logică. O legătură BD 
conţine următoarele informaţii: - protocolul de rețea; - numele nodului; - numele BD 
[utilizator/parola]; - opțiuni protocol. De notat că legăturile nu sunt de la nici-un UID 
identificator utilizator) particular din BDL de origine la un UID specific din BDL destinaţie. 
Fizic, legătura de baze de date, este un pointer (stocat în dicţionarul de date) care definește o 
cale de comunicare cu sens unic de la un server de baze de date la altul. Pentru a accesa 
legătura trebuie să ne conectăm la baza de date care confine intrarea (descrierea legăturii) în 
dicţionar. Pentru ca legătura să poată fi realizată fiecare bază de date din sistemul distribuit 
webuie să aibă un nume unic global (Global Database Name — identifică unic server-ul în 
sistemul distribuit) în domeniul rețea. Legăturile de bază de date pot fi create cu instrucţiunea 
CREATE DATABASE LINK: 


CREATE [SHARED] [PUBLIC] DATABASE LINK dblink [ CONNECT TO f 
CURRENT. USER | user IDENTIFIED BY password [authenticated. clause] } 
| authenticated clause ] 

[USING 'connect string]; 


Numele legăturii este de regulă acelaşi cu numele global al bazei de date. O legătură 
de baze de date este schema unui obiect într-o bază de date care permite accesul la obiectele 
din altă bază de date. O legătură odată creată permite, de exemplu, referirea tabelelor şi 
vederilor din altă bază de date. 

Legăturile de tip bază de date pot fi: 

-~ private, reprezentate de legături într-o schemă specifică a bazei de date locale. La 
aceste legături numai proprietarul sau procedurile PL/SQL pot accesa obiectele 
corespondente din baza la distanță. Aceasta legătură este mai sigură deoarece se 
asigură un acces controlat. De exemplu, comanda: 

CREATE DATABASE LINK sales.uk europe.acme_auto.com; creează o legătură privată care 
utilizează userid/password ale utilizatorului conectat 

CREATE DATABASE LINK link 1 CONNECT TO CURRENT. USER USING "us. supply"; 
creează o legătură privată numită link 7 la baza de date cu numele serviciului us supply 

-~ publice, o legătură de baze de date extinsă. O astfel de legătură poate fi utilizată de 
orice utilizator şi subprogram PL/SQL din baza de date pentru a accesa baza la 
distanță. Este eficientă deoarece asigură partajarea legăturilor dar nu mai este atât 
de sigură ca cea privată. De exemplu, comanda: 

CREATE PUBLIC DATABASE LINK sales.germany.europe.acme_auto.com; creează o 
publică care utilizează userid/password ale utilizatorului conectat 

CREATE PUBLIC DATABASE LINK legatura publita CONNECT TO CURRENT USER 

USING "uk. supply'; creează o legătură publică numită legatura. publica la baza de date cu 

numele serviciului uk supply. 

- globale, o legătură extinsă de reţea. O astfel de legătură este posibilă la utilizarea 
serverelor de nume (acestea crează si gestionează automat legături de baze de date 
globale pentru fiecare bază de date Oracle din rețea). O astfel de legătură poate fi 
utilizată de oricare utilizator și/sau procedură PL/SQL a bazelor de date pentru a 


accesa obiectele în baza la distanţă indicată de legătură. Aceste legături permit o - Legăturile BD definite sunt memorate în dicţionarul datelor BDL de origine 

E 4 eg Las 

gestiune centralizată şi simplă. iz USER DB LINKS, ALL DB LINKS şi DBA DB LINKS). VSDBLINK permite 
i conexiunilor deschise în cadrul unei sesiuni, iar GVSDBLINK permite vizualizarea 


Usor Scart. 


ilor deschise in sesiune împreună cu instanţele co: 
O legătură poate fi utilizată dedicat sau partajat. O legătură partajată are loc între un 
proces al bazei de date locale si baza la distanţă (mai multe procese client pot utiliza aceeaşi 
simultan). Partajarea permite reducerea conexiunilor dintre baza de date locală si cea la 


1 Administrarea BDD. ABD trebuie să-şi asume responsabilitatea pentru întreaga BDD. 
ID este o singură persoană sau mai multe (un grup). In cazul în care există mai multe 
pe acest rol ele trebuie să-şi coordoneze activitatea pe toate aspectele BDD: reţea, 
proiectarea BDD, securitatea si integritatea datelor distribuite, performanţe. 
Protocolul de realizare în două faze. O tranzacţie distribuită poate implica alterarea 
datelor din mai multe baze de date şi, în consecinţă, prelucrarea distribuită este mai complicată 
decât cea normală deorece Oracle trebuie să coordoneze revenirea sau realizarea (consemnarea) 
schimbării ca un obiect unitar. Tranzacţiile distribuite sunt tranzacțiile care fie citesc date din 
mai multe BDL fie modifică date din mai multe BDL. Pentru a asigura prelucrarea cererilor 
Oracle implementeaza Protocolul de Realizare in Doua Faze - 2PC (mecanizmul de realizare în 
Č două faze). Protocolul de realizare în două faze asigură fie execuţia corectă şi completă a 
tranzacţiei, fie anularea peste tot a efectelor tranzactiei. Toate nodurile participante în tranzacţia 
7 distribuită trebuie să execute acecasi acţiune: ele trebuie fie să realizeze toate fie să revină toate 
T la starea dinaintea execuţiei tranzacţiei. 
Protocolul de realizare în două faze asigură transparența actualizărilor distribuite la 
multiplele defecţiuni care pot apărea în rețeaua pe care se lucrează. 
- n pn Á " à Reluam modul de utilizare a protocolului de realizare in doua faze (ca tratare 
Legăturile publice respectă mai puţin securitatea datelor decât cele private, deoarece aici - implementată de Oracle): 


Fig. 10.14. Database Link 
(Sursa: Oracle9i Database Administrator's , 
Gd eleme 2032) Pan Nonler AS63210) 


au fost incluse toate tabelele de la distanţă si toate privilegiile pentru comunitatea de utilizatori - Faza de pregătire - la lansarea/initierca unei actualizări distribuite, nodul de unde se 
care folosesc această legătură (mai mult decât are nevoie fiecare utilizator in parte), dar în lansează tranzacţia devine nod coordonator global (global coordinator) pentru acea 
acelaşi timp simplifică activitatea de creare a legăturilor. Asigurarea transparenţei locației poate tranzacție. El analizează tranzacţia şi determină bazele de date locale ce vor participa 
fi făcută prin utilizarea vederilor, definirea de sinonime sau utilizarea de proceduri, Orc: | - la execuția tranzaciiei. Le transmite tranzacţia sau părți ale acesteia şi ordinul 
permite crearea de sinonime pentru tabele, tipuri de date, vederi, vederi materializate, secvente. i "PREPARE! (cu excepția nodului Commit Point Site). Dacă apar incidente la această 
proceduri, funcții si pachete. : 4 M transmitere coordonatorul anulează tranzacţia. Dacă totul a decurs normal așteaptă 
În unele Situaţii este necesar să se declare mai multe legături de acelaşi tip care si 3 răspuns de la BDL-uril implicate. Dacă primeşte un raspuns de 'ABORT' de la cel 
puncteze la aceeași bază de date dar care să utilizeze alte căi de acces. Oracle permite = puţin una din ele coordonatorul anulează tranzacţia. Dacă primeşte raspuns 
declararea legăturilor de baze de date cu specificarea numelui serviciului optimal (califica | * "PREPARED! de la toate atunci faza de pregltire s-a fncheiat și se trece la faza a 
de conexiune introdus cu simbolul (4). Tipurile de legături utilizator sunt ilustrate în tabelul Y doua. Nodul de realizare (Commit Point Site) are ca sarcină iniţierea operaţiilor de 
UD realizare sau revenire conform instrucţiunilor primite de la nodul coordonator 
global. Pregătirea unui nod înseamnă 
Tabelul 10.2. Tipurile de legături utilizator E 3 * înregistrarea informaţiei in fişierele jurnal online ‘redo logs’; 
| Tip Legătura [Descriere ~ iod m FUND o plasarea unei blocări distribuite pe tabelele modificate pentru a preveni citirea 
| Legătura Utilizator | Utilizatorii se conectează la baza la distanță cu numele şi parola - lor. ma 
| Conectat ! lor (au un cont cu acelaşi nume de utilizator şi parolă atât în baza E Pasii in faza de pregătire pentru fiecare nod participant cu excepția sitului punct de 
| | locală cát si în cea la distanţă. i realizare (commit point site): m" EE 
| Legătura Utilizator 7 | Utilizatorii se conectează la baza Ia distanţă cu numele şi parola i Nodul oes co died €, aickptürlesetsaedut cent, s 
| Fix : lor referite în legătură. pregătească de teala; ete ie RU 
ei Ur [Un utilizator se conectează ca utilizator global. Un utilizator repatriate ancore a 
Curent | pebiecboca di ie bc pasilor si returnează răspunsul numai citire (read-only); 
parr Dei pope e Nodul alocă resursele necesare realizării tranzacţiei dacă datele se schimbă; 


utilizatorului într-o definire de legătură. 
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e Nodul salvează înregistrările de revenire corespunzătoare tranzacţiei 
fişierul jurnal online (online redo log); 
©  Nodurile garantează că blocările făcute pentru tranzacţie sunt capabile să 
supraviețuiască unei căderii 3i 
* Nodul răspunde nodului inițiator cu răspunsul “PREGĂTIT” sau dacă unu} 
din descendenţi nu a putut realiza pregătirea cu răspunsul “ABORT”. — . 
Faza de realizare - coordonatorul transmite ordinul 'COMMIT la BDL-urle 
implicate si aşteaptă mesajul 'TERMINATED' de la fiecare din ele. Dacă apare uy 
incident în cadrul acestei faze rezultatul este neschimbat iar tranzacţia este 
considerată realizată. La BDL cu incidentul, după repunerea în funcțiune, o 
automată determină stadiul în care ajunseseră tranzacțiile care se executay 
la momentul căderii, si în funcţie de acesta se realizează sau se face revenire 
(rollback). Faza de realizare constă în pașii: 
e Coordonatorul global instrucţionează situl punct de realizare să realizeze; 
* Situl punct de realizare realizează; 
* Situl punct de realizare informează nodul coordonator global că a realizat; 
* Coordonatori globali si locali transmit un mesaj tuturor nodurilor 
instrucfionándu-le să realizeze tranzacţia; 
* La fiecare nod, Oracle realizează porțiunea locală din tranzacţia distribuită şi 
deblocheză înregistrările; 
* La fiecare nod, Oracle înregistrează o intrare adițională în fişierul redo log 
local indicând că tranzacţia s-a realizat; 
*  Nodurile participante notifică nodul global coordonator că au realizat. + 


La Oracle implementarea 2PC are unele particularităţi si anume: "uz! 


nodul BD de unde se lansează tranzacţia este Coordonator Global (Global 
Coordinator - GC); 

nodul BD care trebuie să facă acces la alte noduri pentru a-și completa partea sa de 
— eie di) (Local Coordinator - LC); 

fiecare BDD are un CPS (Commit Point Strength - este un parametru de 
iniţializare COMMIT POINT. STRENGTH cu valori între 0 si 255), care reprezintă 
importanța pe care o joacă acel nod de BD în procesul de realizare. Un nod BD cu 
CPS mai mare are prioritate mai mare decât un nod BD cu CPS mai mic; i 
nodul BD cu CPS cel mai mare dintre nodurile BD care participă la execuția 
TERDUM NGG 8 Pi (oul Put Sp). rS Co aa dd 


anuleze tranzacţia în funcție de decizia luată de GC. Când o BDL este în faza de 
pregătire, ea blochează datele ce vor fi afectate de tranzacţie, execută tranzacţia | 


(Commit Point Site) este primul care realizeaza schimbările în BDL. Apoi 
celelalte noduri implicate, din ierarhia distribuită, realizează tranzacţia în 

CPS-ului lor. După realizare fiecare transmite la GC mesajul de terminare. Când 
primit toate mesajele GC îl informează pe CPS (Commit Point Site) că s-a termi 
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şi apoi marchează tranzacţia ca realizată. Dacă un nod de BD cade la momentul 
realizării, procesul RECO (recovery) al acelui nod va reface automat BDL când 
aceasta va fi restartată şi va decide realizarea sau anularea tranzacţiei. Procesul 
RECO utilizează informaţiile din tabela dicționarului DBA-2PC-PENDING, 


10.6.2. Implementarea distribuţiei în DB2 


IBM propune o soluție de distribuire pentru sisteme de gestiune a bazelor de date 
reafionase denumită DRDA (Distributed Relational database Architecture) şi o soluţie de 
distribuire care admite surse de date eterogene (fişiere XML, baze de date de orice tip cic) 
denumită Federated Database (baza de date federativă). 

DRDA. DRDA este un set de protocoale care permit atât sistemelor de baze de date 
multiple, IBM si non-IBM, cát şi aplicaţiilor multiple să lucreze împreună. Orice combinaţie 
de sisteme de gestiune a bazelor de date relajionale care utilizează DRDA pot fi conectate 

a forma un sistem relajional distribuit. Sistemul distribuit utilizează noţiunile de unitate 
de lucru (UOW) şi unitate de lucru distribuită (DUOW). 

O unitate de lucru (UOW - Unit Of Work) este o singură tranzacţie logică constând 
dintr-o secvență de instrucţiuni SQL care fie este prelucrată cu succes (toate operaţiile sunt 
realizate cu succes) fie este considerată în întregime eşec (chiar dacă numai una din operaţii 
este eşec iar celelalte sunt încheiate cu succes). 

O unitate de lucru distribuită (DUOW — Distributed Unit Of Work), cunoscută şi sub 
numele de actualizare multi-sit, implică mai mult de un server de baze de date $i are 
caracteristicile: 

- unitate de lucru actualizează mai mult de un server de baze de date; 

- aplicația direcţionează distribuţia si iniţiază realizarea; 

-= pot fi mai multe cereri pe unitatea de lucru; 

- există un singur server de gestiune pe cerere; 

- realizarea este coordonată pe mai multe servere de baze de date. 

Protocolul de realizare în două faze. În figura 10.14 sunt ilustraţi paşii parcurşi la 

realizarea unei tranzacţii distribuite utilizând protocolul în două faze. Semnificaţia 

paşilor ilustrag în figura 10.15. este: 

- ` Aplicația este pregătită pentru protocolul de realizare în două faze (prin opţiuni de 
precompilare sau configurarea interfeţei de apel (CLI-Call Level Interface); 

- Atunci când un client vrea să se conecteze la baza de date SAVINGS DB 


tranzacţii (TM) Dacă parametrul de configurare al tm database este setat la 
ÍST CONN atunci SAVINGS DB devine gestionar al tranzacţiei (transaction 
manager) pe durata instanței acestei aplicaţii; 

- Conectarea la SAVINGS DB este acceptată si efectuată; 

- Baza de date client începe actualizarea tabelei SAVINGS ACCOUNT (cont de 
economii; depozit). Aceasta incepe unitatea de lucru. Baza de date TM răspunde 
bazei de date client furnizând un identificator tranzacţie (transaction ID) pentru 
unitatea de lucru; 

- Dupà primirea identificatorului de tranzacție baza de date client înregistrează 
unitatea de lucru cu baza de date care conţine tabela SAVINGS_ACCOUNT, bază 
care răspunde clientului ca înregistrarea s-a efectuat cu succes; 

- Cererile transmise câtre SAVINGS DB sunt manipulate normal, Răspunsul la 
fiecare instrucțiune încorporată în program este returnat în SQLCA; 


-". Identifieatorul de tranzacţii este înregistrat în baza de date FEE DB (onorariu) 
care conţine tabela TRANSACTION FEE, la primul acces la această bază de date 
efectuat în cadrul unității de lucru; 

- Toate instrucţiunile SQL adresate bazei de date FEE DB sunt manipulate în 
modul normal; 

- Pe baza de date SAVINGS DB pot fi rulate cereri SQL adiţionale setând 
conexiunea după cum este necesar. Deoarece unitatea de lucru s-a înregistrat în 
SAVINGS_DB în pasul 4 baza de date client nu mai trebuie să parcurgă din nou 


acest pas; 

- Conectarea la si utilizarea bazei CHECKING DB (cont curent) urmează aceleaşi 
reguli descrise în 6 şi 7; 

- Atunci când baza de date client cere realizarea unităţii de lucru se trimite mesajul 
“pregăteşte” (prepare) la toate bazele de date care participă la unitatea de lucru. 
Fiecare bază de date scrie o înregistrare “PREPARED” în fişierul log, şi răspunde 
bazei de date client; 

- După ce baza de date client primeşte un răspuns pozitiv, de la toate bazele de date, 
trimite un mesaj bazei de date de gestiune a tranzacţiei (TM) pe care o informează 
ca este gata de realizare (PREPARED). Baza de date de gestiune a tranzacţiei seric 
o inregistrare" PREPARED" în fişierul său log şi trimite un răspuns la client pentru 
al informa ca poate starta Faza Doi a protocolului; 

- Pe durata fazei doi a protocolului de realizare baza de date client trimite un mesaj 
tuturor bazelor participante prin care le cere sa realizeze (COMMIT). Fiecare bază 
de date scrie o înregistrare "COMMITED" în fişierul său log şi eliberează 
blocările realizate în timpul lucrului. Când o bază termină realizarea trimite un 
răspuns clientului; 

-  Dupi ce baza de date client a primit răspunsuri pozitive de la toate bazele de date 
participante trimite un mesaj gestionarului de tranzacţii prin care confirmă 
realizarea unităţii de lucru. Baza de date de gestiune a tranzacţiilor scrie 0 
înregistrare “COMMITED” în fişierul său log indicând că unitatea de lucru este 
realizată, şi răspunde clientului indicând că a terminat. 

Sistem Federativ. Un sistem federativ (figura 10.16) este un tip special de sistem de 
gestiune a bazelor de date distribuite care constă din una sau mai multe instanţe de baze de 
date DB2 care operează ca server federativ, o bază de date care acţionează ca o bază 
federativă, una sau mai multe surse de date si, clienţi (utilizatori şi aplicaţii) care accesează 
baza de date sí sursele de date. Intr-un astfel de sistem se pot adresa cereri SQL distribuite 
multiplelor surse de date pe care le gestionează. De exemplu, cu o singură instrucțiune SQL. 
se pot joncfiona date localizate într-o tabelă DB2, o tabelă Oracle şi un fişier XML. Sursele de 
date în sistemul federativ sunt autonome si pot fi reprezentate, de exemplu, de baze de date 
relaţionale (ca Oracle sau Sybase) sau surse non-relaţionale (cum ar fi un fişier XML, de 
exemplu). Autonomia surselor de date se referă la faptul că, de exemplu, serverul federati 
poate trimite o cerere la o bază de date Oracle si în același timp aplicaţiile Oracle pot acces? 
aceeaşi sursă. O altă caracteristică importantă este aceea că prin intermediul unei surse de dsie 
se poate accesa o alte sursă de date, acces efectuat cu metoda sau protocolul specific tipului de 
sursă. 


Un sistem federativ are abilitatea de a: 

- . corela datele din tabelele locale și sursele la distanţă ca și cum toate datele ar 
stocate local in baza federativă; 

- actualiza datele în sursele relajionale ca şi cum datele sunt stocate in b4 
federativă; 

- muta datele în si din sursa relaţională; 
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despre obiectele bazei de date federative cát şi despre obiectele ce iz sursel 

» Interacțiunea bazei de date federative cu sursele de date este realizz-3 prin 

mecanismelor denumite „wrapper” (supracoperta) reprezentate de rutine socete 

sa „modul supracopertă” (wrapper module). Puneţiunile specifice realizes 4 

»Supracopertá" sunt reprezentate de: 

- conectarea la sursa de date (prin conexiunea standard API); 

- transmiterea cererilor sursei de date exprimate în SQL, pentru s:=sele de ¿aie care 
suportă SQL, sau exprimate in limbajul nativ de cereri al sursei, pentru sursele cec 
nu suportă SQL; 

- primirea rezultatelor de la surse (prin intermediul unei serii de apeluri API) 

- a răspunde cererilor bazei de date federative privind mapările i: 
date pentru o sursă de date; 

- a răspunde cererilor bazei de date federative privind mapările implicite e 
pentru o sursă de date. 

- profita de puterea de prelucrare a surselor de date prin trimiterea la aceste surse a 
cererilor pentru prelucrare; 

- compensa pentru limitările SQL la sursa de date prin preluczezea uno păr čz 
cererea distribuită la server-ul federativ. 
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Fig. 10.16. Componentele unui sistem federativ 


Aplicațiile nu necesită instrucțiuni speciale pentru a interacționa cu datele federate ci 

n ; den N : ^ " Tale Ci m 
interactioneaza iile oricărei aplicaţii client DB2: aplicaţia trimite cereri SQL bazei de date. 
federative care distribuie cererea sursei de date s, col i i 

core zi rai propice, colectează datele cerute şi retumnează 2 


i 
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11.1. Prezentare generalá 


11.1.1. Noţiuni de bază 


Încă de la începuturile erei informatice, managerii au înţeles că datele stocate de 
sistemele informatice operaționale reprezintă o mină de aur informaţional care se cere 
exploatată. Eforturile în această direcţie au născut generaţii de acronime: MIS (Management 
information Systems - sisteme de management al informaţiei), DSS (Decision Support 
Systems - sisteme suport de decizie), EIS (Executive Information Systems - sisteme 
informatice executive), MSS (Management Support Systems - sisteme suport pentru 
management). 

Depozitele de date, sub un nume sau altul, au apărut în gândirea comunităţii 
informatice la sfârșitul deceniului trecut. Acestea reprezintă o cerinţă acută a organizaţiilor 
moderne (fie ele întreprinderi, bănci, administraţie etc.) şi, totodată, o realitate tehnologică 
pusă în practică din ce în ce mai frecvent. Ultimele cifre estimate de IDC referitoare la piaţa 
depozitelor de date indică faptul că aceasta va înregistra o creştere de 9% până în 2009, 
atingând o valoare de 14.5 miliarde de dolari, unde momentan volumul său este de 
aproximativ 10 miliarde de dolari. De asemenea, Gartner Group estimează o creştere dublă pe 
piaţa depozitelor de date în raport cu creşterea globală a pieţei de IT. 

Depozitele de date sunt produsul mediului economic şi al tehnologiilor avansate. Din 
perspectivă economică, globalizarea comerțului, acutizarea dramatică a concurenţei, 
reducerea spectaculoasă a ciclurilor de viață al produselor datorită dinamicii tehnologiei şi 
impunerea unor cerințe calitative extrem de ridicate au evidenţiat sí mai mult valoarea 
strategică a informaţiei. Manipularea operativă a informaţiei a impus la rândul ei două modele 
manageriale, mai suple şi mai adecvate din punct de vedere funcţional. Nevoia de a răspunde 
în timp optim cerințelor pieţei a condus la descentralizare si la reducerea numărului nivelelor 
decizionale, consacránd așa-numitele "ierarhii plate", care se bazează pe delegarea puterii 
decizionale operative către eşalonul managerial secund. Practic, clasicul funcționar este pe 
cale de a fi înlocuit de "lucrătorul cu informaţii”. Atât la nivelul conducerii strategice, cát si la 
nivelul managementului operativ, nevoia de informaţie pură, corectă şi semnificativă a 
devenit vitală. 

Din perspectivă tehnologică, ultimii ani au adus puterea de calcul la prețuri accesibile. 
Servere paralele bazate pe  microprocesoare ieftine rivalizează ca putere cu 
Supercalculatoarele, la o fracțiune din preţul acestora. Sistemele de baze de date pot exploata 
la maximum arhitecturile hardware paralele, iar evoluţiile spre sisteme deschise permit o 
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conectivitate aproape totală la orice fel de surse de date şi interoperabilitate între diverse 
platforme software/hardware. Mediile de stocare magnetice si optice admit volume de ordinul 
giga şi chiar terabytes. 

Microcalculatoarele au ajuns si ele la maturitate. Puterea lor este acum suficientă 
pentru funcţiile de analiză si prezentare care le sunt rezervate, iar interfețele grafice intuitive 
le fac accesibile utilizatorilor neprofesionisti, în speța managerilor. 

Sistemele informatice operaţionale există, datele pot fi accesate oriunde, nevoia de 
informaţie este acută, puterea de calcul si de stocare este ieftină, instrumentele software sunt 
accesibile, toate acestea creează un cadru favorabil implementării depozitelor de date. 

„Rolul unui depozit de date este de a oferi o imagine coerentă asupra datelor referitoare 
la activitatea unei organizaţii si a contextului în care aceasta acţionează. Spre deosebire de 
colecţiile de date utilizate de sistemul operațional - orientate spre optimizarea şi siguranța 
procesării datelor - datele dintr-un depozit de date sunt organizate într-o manieră care să 
permită analizarea lor, deci extragerea semnificației economice pe care o poartă. Depozitul de 
date separă spaţiul de lucru al analizei de spaţiul de lucru al tranzacţiilor şi oferă posibilitatea 
organizaţiilor să consolideze datele din mai multe surse. Sursa principală sunt sistemele 
operaţionale, iar ca surse secundare pot fi atât surse interne, cât şi surse externe, cum er fi 
bazele de date publice: date statistice furnizate de instituţii specializate, date de prognoză 
economică furnizate de instituţii orientate pe studiul pieţei, date obţinute în urma unor sondaje 
de opinie, etc. 

William Inmon, vicepreședintele firmei Prism Solutions, este considerat părintele 
necontestat al noţiunii „depozit de date” în înțelesul ei curent, deţinând de altfel trademark-ul 
termenului „data warehouse”. Viziunea sa despre depozitele de date se concentrează asupra 
rolului acestora de bază informaţională a deciziei manageriale, păstrând astfel un nivel înalt 
de generalitate şi permiţând unor multiple implementări să intre în sfera acestei noțiuni. 


Definiţia lui Inmon este extrem de concisă: “Un depozit de date este o colecţie de date 
orientate pe subiecte, integrate, istorice şi nevolatile, fiind destinată fundamentárii deciziei 
manageriale. “ 


În continuare vor fi prezentate caracteristicile evidenţiate de această definiţie. 


- Orientare pe subiecte 

Datele operaţionale sunt orientate pe aplicaţii, în sensul că organizarea lor este 
optimizată pentru a servi procesului tranzacțional, dinamicii sistemului. În contrast, depozitul 
de date este orientat pe subiectele importante ale procesului economic, cum ar fi: clienți, 
furnizori, produse, activităţi. Aceste subiecte necesită informaţii din diferite surse pentru 2 
furniza o imagine completă a domeniului. În loc de a se concentra pe procesarea operaţiilor $i 
tranzacţiilor zilnice dintr-o organizaţie, un depozit de date se focalizează pe modelarea și 
analiza datelor pentru luarea deciziilor. Din acest motiv, depozitele de date oferă, în mod 
tipic, o viziune simplă si concisă, relativă la un subiect specific, excluzând datele care nu sust 
utile în procesul de sprijinire a deciziei. 

Un exemplu simplu poate fi edificator: o comandă lansată de un client va fi 
consemnată de sistemul operaţional printr-un set de înregistrări care vor conţine informați 
despre client, informaţii despre produsele sau serviciile comandate, informaţii despre mod 
de transport şi modul de plată, etc. Atenţia sistemului tranzacjional este orientată căi 
consistenţa cheilor, astfel încât operaţia să păstreze consistență. Multe dintre datele esențiale 
din perspectivă operaţională (numărul comenzii, poziţiile liniilor în cadrul comenzii etc.) S% 
complet lipsite de relevanţă din perspectivă informațională. 
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O consecință importantă a acestei orientări este redundanfa datelor. Dacă în sistemul 
operațional redundanța este controlată (prin procesul de normalizare) pentru a evita anomaliile 
de actualizare, în depozitul de date redundanfa este creată in mod intenționat (prin 
Jdenormalizare şi sumarizare) pentru a permite un acces tematic mai facil. 


- Integrare 

Este cel mai important aspect al depozitului de date si, în cele din urmă, raţiunea 

Tpentru care acesta este creat. Datele sunt adunate aici pentru a răspunde nevoilor 
informaţionale ale întregii organizaţii, asigurând faptul că rapoartele generate pentru diverse 
compartimente vor conţine aceleaşi rezultate. Sistemul operaţional este de cele mai multe ori 

“format din subsisteme semiindependente, create la momente diferite, de echipe diferite, in 

— maniere diferite, iar rezultatul, deşi funcţional, este imposibil de folosit pentru analiză. 

Integrarea unor multiple surse heterogene: baze de date relationale, fişiere, înregistrări 

"privind tranzacţiile on-line, impune implementarea unor tehnici de curăţire a datelor (data 
cleaning) si de integrare pentru a se asigura consistenta datelor din depozit. 

T. Caracterul istorie 

Sistemul operațional al unei organizaţii tinde mereu să reflecte realitatea curentă. 

- Astfel, el se află într-o continuă evoluție, iar datele pe care le conține sunt relevante doar 

"pentru momentul în care sunt accesate. Orizontul de timp pe care il acoperă este de regulă de 

„60 până la 90 de zile, deoarece după acest interval tranzacțiile efectuate sunt arhivate, fiind 
considerate deja de domeniul istoriei, deci neinteresante din perspectivă operativă, 

i Pentru nevoile analizei economice, dimpotrivă, informațiile cu caracter istoric sunt 
esenţiale, deoarece ele pun în evidență tendințe care reprezintă fundamentul unei prognoze 
corecte. Depozitul de date se constituie într-un istoric al sistemului operațional, constituit 
dintr-o serie de "instantanee", imagini la diverse momente în timp. Orizontul de timp pe care 

-il acoperă depozitul de date este de cel puțin cinci ani, ajungând uncori la zece anl, în funcție 

„de dinamica evoluţiei pieței si, deci, de relevanfa datelor cu caracter istoric pentzi nevoile 

{ analizei. = 

Din punct de vedere tehnic, acesta implică faptul că orice înregistrare din depozitul de 
poate fi plasată în timp. Orice cheie de acces cuprinde şi o variabilă temporală, 


date 


Persistenfa datelor 
Esenţa aplicaţiilor operaționale este actualizarea continuă a colecţiilor de date, 


„adăugarea unor noi înregistrări, modificarea sau eventual ştergerea altora etc. Cu totul altfel 
su lucrurile în cazul depozitului de date, unde o astfel de dinamică lipseşte. În mod uzual 
- sunt solicitate doar două operațiuni în accesarea datelor: încărcarea iniţială a datelor si accesul 
{la date pentru citire. Practic, singura actualizare care se realizează este adăugarea periodică a 
“unor date extrase din sistemele operative. 
P, Din punctul de vedere al proiectării, această diferenţă este extrem de importantă. În 
Sistemul operațional, o tranzacție trebuie să ducă colecția de date dintr-o stare consistentă într- 
je altă stare consistentă, iar aceasta implică mecanisme extrem de complexe de menţinere a 
Întegrităţii datelor, mai ales în situația sistemelor intens concurențiale: mecanisme de 
izare, mecanisme de salvare/restaurare/refacere, mecanisme de detectare a blocărilor 
firculare (dead lock) etc. În cazul depozitelor de date, aceste mecanisme sunt inutile, astfel că 
adu de libertate câştigat poate fi utilizat pentru optimizarea accesului la date prin 
denormalizare, sumarizare, statistici ale accestrii datelor si reorganizare dinamică a indexării 
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11.1.2. Obiectivele unui depozit de date e 
* 

Primele domenii care au adoptat tehnologia depozitelor de date au fog 
telecomunicajiile şi comerțul cu amânuntul. Ulterior, depozitele de date au pătruns si în ae" 
domenii cum ar fi industria farmaceutică, sistemul sanitar, asigurări, transporturi. Studiile" 
statistice arată că telecomunicatiile şi sistemul bancar se menţin în top, întrucât alocă cel putin 
15% din bugetul IT pentru proiecte referitoare la depozite de date. x 


Ci E S antri bs a depotit ana 
- Executarea unor activități de server/disc asociate cu interogarea și raportarea 
servere/discuri care nu sunt utilizate de sistemele de paai tranzacţiilor.” 
Firmele vor ca sistemele să proceseze o tranzacţie într-un timp rezonabil. 
Rapoartele şi interogările, utilizând în mod variabil resursele fizice (server/disc), 
încetinesc procesarea tranzacţiilor, şi fac ca serverele/discurile să fie dificil de! 
organizat. De aceca, firmele pot considera că implementarea unei arhitecturi data 
warehouse care utilizează servere/discuri separate este un mod mai ieftin sau/și 
mai organizat de a obține un timp de procesare a tranzacţiilor acceptabil. Procesele 
decizionale şi procesele operaţionale sunt total divergente arhitectural. $ 
- Urilizarea unor modele de date şi/sau tehnologii server care accelerează. 
interogarea şi raportarea şi care nu sunt adecvate pentru procesarea. 
tranzacţiilor. Există modele de date care accelerează interogarea și raportarea (de 
exemplu, schema stea, vezi 11.4.1) şi care nu sunt adecvate pentru procesarea 
tranzacţiilor, pentru că tehnica de modelare o va încetini si compliea. De 
asemenea, există şi tehnologii server care pot îmbunătăţi viteza pentru interogare și 
raportare, dar încetinesc procesarea tranzacfionalà (indexarea de tip bitmap) $i - 
pun tehnologii care acționează în sens invers (tehnologii pentru restaurarea - 
latelor). ; 
- Furnizarea unui acces sporit la date pentru utilizatori. Depozitul de date 
furnizează accesul la datele integrate ale întreprinderii, anterior blocat prin căi 
neprietenoase. Utilizatorii pot acum să stabilească, cu un minim de efort, o 
conexiune garantată la depozitul de date prin intermediul unui calculator. i 
-  Oferirea unui depozit de date "curățat", furnizând o singură versiune a realității. 
Depozitul de date oferă posibilitatea de a curăța datele fără modificarea sistemului 
de procesare a tranzacţiilor, Datele din depozitele de date sunt consistente şi au 
calitatea asigurată înainte de a fi puse la dispoziția utilizatorilor. În măsura în care - 
se utilizează o sursă comună de date, depozitele de date pun capăt 
privind veridicitatea datelor utilizate pentru realizarea rapoartelor. z 
- Facilitarea interogării şi raportării pe date provenite din mai multe n 
tranzacţionale şi/sau din surse externe de date. Multă vreme firmele care ave: 
nevoie de rapoarte bazate pe date provenite din mai multe sisteme au 
această problemă prin extragerea, sortarea și combinarea datelor, în final 
în execuție rapoarte asupra lor. În multe cazuri această soluţie este una ade 
Dar, dacă o companie are multe date care trebuiesc sortate/combinate 
dacă datele din sistemele tranzacfionale trebuie "curățate", atunci soluția 


oferite de depozitele de date reduc timpul şi efortul necesar pentru colectarei 
formatarea si filtrarea informaţiilor plecând de la date. 
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- Înregistrarea cu acuratețe a trecutului. Datele istorice sunt deseori eliminate din 
sistemul de procesare a iilor pentru a optimiza şi controla timpul de 
răspuns al sistemului. Pentru interogare şi raportare, aceste date şi datele curente 
pot fi stocate în depozitul de date în cadrul căruia timpul de răspuns așteptat se află 
la un nivel mai ridicat. 

-  Împiedicarea persoanelor care au nevoie de acces doar pentru raportare şi 
interogare să aibă acces la bazele de date ale sistemului de procesare a 
tranzacţiilor. Acest punct priveşte securitatea. De exemplu depozitul de date poate 
fi un punct de interes pentru firmele care doresc să permită raportarea și 
interogarea prin intermediul Internetulul. 


Un proiect pentru depozite de date reprezintă însă o investiţie riscantă şi scumpă. 
Costurile tipice pentru dezvoltarea unui depozit de date într-un interval de 3-6 luni se situează 
intre 0,8 şi 2 milioane USD. Ponderea echipamentelor se situează între 1/2 si 2/3 din costul 
vota al proiectului. O soluție pentru firmele mici şi mijlocii este recurgerea la data marts 
pentru care costurile se situează sub 100.000 USD într-un interval adesea sub 90 de zile. 
Uneori investiţiile în depozitele de date nu se finalizează cu succes. Motivaţiile cele mai des 
iatâlnite pentru eşecul unor depozite de date includ: 

* Lipsa de înțelegere a complexității proiectelor de business intelligence; 

* Lipsa de înţelegere a faptului că soluțiile de business intelligence implică cel mai 
adesea subunitati multiple ale companiei, ceca ce le face diferite de soluțiile stand- 
alone; 

Reprezentanţii companiei sunt indisponibili sau neinteresafi; 

Lipsa de personal pregătit disponibil sau utilizarea suboptimală a acestuia; 
Structura inadecvată a echipei de proiect; 

Lipsa unei abordari iterative în dezvoltarea soluţiei; 

Management de proiect ineficient; 

Lipsa de metodologie; 

Lipsa de apreciere asupra impactului datelor necurățate asupra profitabilităţii; 
Nu este înteleasă necesitatea utilizării metadatelor; 

Utilizarea de metode și instrumente disparate, 


11.2. Arhitectura depozitelor de date 


Depozitul de date conţine date care sunt extrase dintr-unul sau mai multe sisteme, 
numite surse de date. Aceasta include o gamă largă de sisteme incluzând baze de date 
relaționale şi baze de date orientate obiect, dar şi baze de date prerelafionale $i sisteme 
moştenite (figura 11.1). 

Arhitectura unui depozit de date confine următoarele componente care nu sunt toate 
obligatorii. Primele două componente operează pe sursa de date. 


integritate şi regulile privitoare la o singură sursă de date. Ele pot, de asemenea, 


satisfăcător al calităţii. Este important să 
verificánd calitatea datelor pe părți mici înainte de a realiza întreaga încărcare. 
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-~ Componenta Export este folosită pentru extragerea datelor din sursele de date, 
Procesul de extragere este incrementat normal, componenta Export construieşte 
colecția tuturor modificărilor pe sursa de date, care sunt apoi importate de 
depozitul de date. 

-  Íncărcătorul este responsabil pentru încărcarea inițială a datelor în depozitul de 
date. Această componentă pregăteşte datele pentru utilizarea operaţională, 
ocupându-se atât de ordonarea şi agregarea operațiilor, cât şi de construirea 
structurilor de date în depozitul de date. În mod standardizat, operațiile de 
încărcare sunt realizate pe grupe, caz în care depozitele de date utilizează 
paralelismul. Acest modul sc ocupă şi cu fragmentarea iniţială a datelor. În unele 
aplicaţii, caracterizate de o cantitate limitată de date, acest model este invoca 
pentru încărcarea întregului conținut al depozitului de date după fiecare schimbare 
a surselor de date. Cel mai adesea, datele din depozitul de date sunt reînnoite 
automat de componenta Refresh care va fi discutată în continuare. 

- Componenta Refresh înnoieşte conţinutul depozitului de date, propagánd automat 
noutăţile apărute în sursele de date. Modificările din sursele de date sunt realizate 
cu ajutorul a două tehnici: transportarea datelor şi transportarea tranzacţiilor. 

* Prima tehnică utilizează triggeri pe sursa de date, care, invizibili pentru 
apli înregistrează ştergerile, inserările şi modificările in fişiere. 
Modificările sunt adesea tratate ca perechi de inserări şi ştergeri. 

* A doua tehnică foloseşte consemnarea tranzacţiilor pentru a construi fişierele 
de modificări. În ambele cazuri, fişierele de modificări sunt transmis 
depozitului de date şi apoi folosite pentru a înnoi depozitele de date; vechile 
valori sunt marcate de obicei ca date istorice, dar nu sunt șterse. d 

- Componenta Acces la date este responsabilă pentru îndeplinirea operaţiilor de 
analiza a datelor. În depozitele de date acest modul compune in mod eficient 
întrebări relaţionale complexe, cu compuneri, ordonări sí agregári complexe. 
Compune de asemenea si operaţii noi specifice dicfionarelor de date, cum ar fi 
împachetări, despachetări şi agregarea totală a datelor. Acest modul este în strânsă 
legătură cu sistemele client care oferă interfeţe prietenoase utilizatorilor, 
compatibile pentru analize complexe ale datelor. 

- Componenta Data mining permite executarea de explorări complexe ale 
informaţiilor ascunse in date, utilizând tehnici şi algoritmi specifici de data 
mining. 

- Componenta de Export al datelor e folosită pentru exportarea datelor prezente într- 
un depozit spre alte depozite, creându-se astfel o arhitectură ierarhică. În plus, 
dicționarele de date sunt adesea dotate cu module care suportă formatul $i 
organizarea lor: 

e Um instrument CASE care poate suporta formatul depozitelor de date; 

* Un dicționar de date descrie conţinutul depozitelor de date este utilizat pentru 
a înțelege ce fel de analiză a datelor trebuie realizată. 

Elementele prezentate legate de arhitectura depozitelor de date trebuie completate de 


câteva consideraţii privind calitatea datelor. 


Calitatea datelor este un element esenţial pentru succesul depozitelor de date. Daci 


datele stocate conţin erori, rezultatul analizei va produce rezultate eronate, şi utilizarea 
depozitelor de date ar putea fi la un moment dat contraproductivă. Calitatea redusă a acestora 
se poate datora unor factori dintre cei mai diverşi, de la proaste obiceiuri, la lipsa de interes 
pentru integrare cu alte zone ale organizației. Oricum este un proces care presupune 1 
consum foarte mare de timp şi bani. 
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t Fig. 11.1 Arhitectura depozitului de date 


z Activităţile care trebuie realizate în cadrul acestui proces sunt următoarele: 
F 1) Analiza datelor de sus în jos (top-down) abordează aspectele referitoare la 
integrarea si consistenţa datelor si presupune realizarea modelului logic al datelor 
la nivelul organizaţiei, relaţiile între acestea $i modalitătile de integrare a 
modulelor şi surselor existente. Rezultatul acestei etape poate fi reprezentat 
sintetic sub forma unui model entitate-asociere. 4 
2) Analiza datelor de jos în sus (bottom-up) abordează aspectele referitoare la 
standardizare si calitate. Se definesc reguli de conversie a datelor, reguli de 
integritate şi reguli referitoare la domeniile de valori. 
3) Curățarea datelor presupune transformarea şi filtrarea surselor de date. 
1 Procesul de extragere, transformare si încărcarea a datelor (Extract Transform and 
‘Load — ETL) este cel mai complicat proces al dezvoltării unui depozit de date, necesitând, de 
obicei, timp îndelungat. Recomandarea specialiştilor este de a se realiza integrarea tuturor 
bazelor de date destinaţie într-un singur mediu şi construirea procesului ETL în cadrul 
tcestuia, şi nu separat pe fiecare modul destinaţie. Activităţile care trebuie realizate în cadrul 
Acestui proces sunt următoarele: A ce 
i 1) Crearea specificaţiilor de transformare (mapping) a surselor pe destinațiile 
i corespunzătoare (cu ajutorul unor matrice sau diagrame de transformare); 
2) Alegerea şi testarea intrumentelor ETL utilizate; ——— - 
3) Proiectarea procesului ETL presupune proiectarea a diversi operatori de extragere 
şi transformare (pentru sortări, agrcgári, joctiuni, divizări, etc); 
4) Proiectarea programelor ETL care vor fi rulate adecvate etapelor de încărcare: 
i. Încărcarea iniţială — cu date operaţionale curente; 
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ii. Încărcarea cu date istorice —cu date istorice arhivate; 

iii. Încărcarea incrementală -cu date curente provenite din sistemele 
operaționale. 2 

5) Alegerea mediului în care va fi rulat procesul ETL, fie că este vorba despre un - 
server dedicat sau fie că procesul va fi divizat şi va rula descentralizat. 


Instrumentele ETL pot fi grupate astfel: 

- Instrumente pentru conexiunea cu alte sisteme: acestea asigură accesul 
la sursele de date ce provin din medii eterogene. Exemple de astfel de sisteme 
sunt: IBM DataJoiner, Oracle Transparent Gateway, Sybase Entreprise Connect. 


- Instrumente de extragere: acestea asigură preluarea datelor în depozitul de date din 
diversele surse de date. Alegerea si utilizarea acestor instrumente depind de o serie 
de factori, printre care: baza de date si platforma sistemului sursă; funcţionalitățile 
de extragere si duplicare existente; intervalele de timp în care sistemele 
operaționale sunt disponibile. Există două metode de bază pentru realizarea 
extragerii datelor: 
* Extragerea în masă (“bulk extraction"), care presupune extragerea datelor 

corespunzatoare întregului depozit de date; 
* Replicarea, care presupune extragerea doar a acelor date care au fost 
modificate de Ia ultima actualizare. 

Adesea, instrumentele de extragere a datelor pun la dispoziţie facilităţi de curăţare a 

datelor, dar există posibilitatea să fie necesare extensii ale acestora, prin scrierea unor 
proceduri de corecție sau pur şi simplu corecția manuală a datelor. Astfel de facilități sunt: 
completarea valorilor lipsă, corectarea erorilor de introducere a datelor, stabilirea unor 
formate standard, înlocuirea sinonimelor cu identificatori standard. Datele recunoscute ca 
fiind eronate si nu pot fi curățate sunt respinse. Informaţiile culese cu prilejul acestei operații 
pot fi folosite pentru îmbunătăţirea calităţii datelor în timp. 


-~ Instrumente de transformare: acestea asigură maparea corectă a datelor provenite 
din diverse surse, dar care nu au aceeași structură sau același format. Principalele 
funcţii oferite sunt: partiţionarea si consolidarea câmpurilor, standardizarea și 
deduplicarea (tabelul 11.1). 


Tabelul 11.1. Exemple de transformări ale datelor 


Funcție: Director general 


Sistem sursă Tipul transformării 
Câmpul Adresa 
Str. Unirii Nr. 123, Municipiul 
Arad, 6200, România e " E 
Partţionare câmpuri | Ti tocalitate: Municipi 
Cod Postal: 6200 

| Tara: România 
Sistem A, 
Funcție: Manager general 

s ; | Funcție: Manager 

Sistem B, Director general 
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Depozite de date 
Data comenzii: 
pata comenzii: 12 Nov. 2007 y 12 Noiembrie 2007 
Data comenzii: 19-09-07 Buried Data comenzii: 
19 Septembrie 2007 
Sistem A, 
Nume angajat: Ionescu T. Vasile 4 . 
pora B = Deduplicare Name angajat: Ionescu I 
Nume angajat: Ionescu Vasile asile 


- Instrumentele pentru asigurarea calității datelor: acestea asistă la localizarea şi 
corectarea erorilor fie în sistemele sursă, fie în depozitul de date. De preferat este 
ca acest lucru să se realizeze în cadrul sistemelor sursă, lucru care de obicei este 
mai dificil de realizat, deoarece modificările în cadrul depozitului de date pot 
conduce la apariția de inconsistențe în momentul în care se realizează actualizarea 
depozitului. 

Statisticile arată că până la 15% din datele extrase din diferite surse de date sunt 
inconsistente sau incorecte, fapt care poate avea o influență puternic negativă asupra 
rezultatelor analizelor realizate pe baza acestora. Exemple De astfel de sisteme sunt:Data 
Quality Workbench (DataFlux); Content Tracker (Pine Cone Systems); Quality Manager 
(Prism); Integrity Data Reengineering (Vality Technology). 


- Instrumente pentru încărcarea datelor: acestea ajută la încărcarea datelor 
transformate în depozitul de date. Aceste instrumente realizează preformatarea 
datelor în formatul fizic intem cerut de SGBD-ul ţintă şi trebuie să asigure 
integritatea şi consistenţa datelor preluate din sistemele sursă. Indecşii pot încetini 
substanțial procesul de încărcare, motiv pentru care, de obicei, se renunţă la ei 
înainte de încărcare gi apoi se recreează. 


Instrumentele sunt de obicei încorporate în cadrul unui singur instrument, cunoscut ca 
ETL Tool, exemple de astfel de instrumente fiind: Data Junction, Ascential DataStage si 
Informatica. 


11.3. Obiectele depozitului de date 


Într-un depozit de date se întâlnesc mai multe tipuri de obiecte care prezintă o 

importanță deosebită în analiză: 

- Tabelele de fapte — sunt tabelele centrale ale depozitului de date. Acestea contin 
faptele şi cheile externe către tabelele de dimensiuni. Faptele sunt, de obicei, date 
numerice care pot fi totalizate şi analizate pe diferite nivele. 

- Dimensiunile — sunt nişte nişte structuri compuse din una sau mai multe ierarhii 
care structurează datele. Tabelele secundare se numesc tabele dimensiuni, si sunt 
mult mai mici decât tabelele de fapte. Fiecare tabelă dimensiune are câte o cheie. 
Câmpurile dintr-o tabelă dimensiune sunt de obicei textuale si sunt folosite ca 
sursă pentru restricţii şi pentru rândurile din rapoarte. Datele sunt, de obicei, 
colectate la nivelul cel mai de jos şi mai detaliat şi sunt agregate pe nivelele 
superioare pentru analiză. 
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- erarhille — sunt structuri logice utilizate pentru ordonarea nivelelor de 
reprezentare a datelor. Sunt utilizate şi pentru definirea căilor de navigare în 
interiorul datelor. Nivelele ierarhice sunt utilizate de instrumentele de analiză 
OLAP, permițând detalierea graduală a datelor. 


Fig. 112. Ierarhii şi nivele 


- Nivelele ~ reprezintă poziţii în cadrul ierarhiilor. De exemplu, dimensiunea Timp 
poate avea trei nivele de ierarhizare: an, trimestru si luna. Nivelele se structurează 
în funcţie de ierarhie de la general la specific, rădăcina fiind reprezentată de 
nivelul superior, cel mai general al ierarhiei. fiile între diferite nivele sunt 
relaţii de tipul părinte-copil. Se pot defini ierarhii în care datele fiecărui nivel sunt 
agregate la un nivel superior sau se pot sări anumite nivele care sunt independente 
(figura 11.2). 

- Atribute — dimensiunile sunt concretizate prin intermediul atributelor care 
reprezintă calificative specifice. Orice atribut se asociază unei singure dimensiuni, 
jar o dimensiune se poate exprima prin mai multe atribute. Cu cât aceste atribute 
sunt mai descriptive, cu atât depozitele de date vor fi mai performante. 

- Metrici (măsuri) — în analiza depozitelor de date se utilizează anumite variabile 
sau metrici. Aceste corespund faptelor din tabelele de fapte si sunt de regulă de 
natură numerică. Exemple tipice ar fi: vânzări, costuri, stocuri. Aceste variabile au 
sens numai în contextul unor anumite dimensiuni. 


11.4. Structura depozitelor de date 


Construcţia unui dicționar de date, care descrie toate datele prezente in companie, estè 
un scop ambițios, adesea greu de obținut. Din acest motiv, construirea unui depozit de dete 
trebuie să se concentreze în mod separat pe subseturi de date ale companiei (cunoscute €* 
"date de departament”), pentru care scopul de analiză este clar. Fiecare schemă simplificată 2 
datelor de departament poartă numele de Data Mart. Fiecare colecţie de date este realizată i 
conformitate cu o structură simplă, numită schemă mulridimensională, termen care implici 
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unor multiple dimensiuni de analiză. Există mai multe scheme de structurare a unui 
it de date: schema stea, schema fulg de zăpadă si schema constelație de fapte. 


1.4.1 Schema stea 


Schema stea este cel mai simplu model de structurare a unui depozit de date, model 
m in figura de mai jos cu ajutorul modelului entitate-asociere. O entitate centrală 
„prezintă faptele pe care este focalizatà analiza. Diferite entități aranjate sub formă de raze in 
guess reprezintă dimensiunile analizei. Mai multe relaţii unu la mulți conectează 
fi element din domeniul faptelor la exact un element al fiecărei dimensiuni. Schema din 
figura de mai jos reprezintă managementul unei rețele de magazine. Entitatea din centrul 
„selei reprezintă vânzările care sunt factori de interes; dimensiunile sunt reprezentate de 
- vândute, magazinele, promoţiile şi momentul fiecărei vânzări (figura 11.3.) 
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Fig. 11.3. Colecţia de date pentru un lan de supermarketuri 
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Fig. 11.4. Colecția de date pentru o companie de asigurări 
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Figura 11.4. reprezintă organizarea plăţilor unei companii de asigurări. Entitatea 
centrul stelei reprezintă plăţile către cci care trebuie onorafi de către companie; i 
reprezintă polifele de asigurare, clienții, timpul si tipul problemelor care au cauzat 
revendicare. 

E Schema din figura 11.5. reprezintă organizarca terapiilor într-un it 
Entitatea din centrul stelei reprezintă terapiile; dimensiunile ear pps 
pacienţii, doctorii in cauză si spitalele in care sunt acceptaţi pacienţii. vi, 

Aşa cum este prezentat în cele trei colecţii de date, principala caracteristică a schemei 
stea este folosirea unei structuri regulate, independentă de problema în cauză. Desigur 
numărul dimensiunilor poate fi diferit, dar cel puțin două dimensiuni sunt necesare (deoarece 
în caz contrar, modelul se descompune într-o simplă ierarhie unu la mulţi). Un număe ridica! 
de dimensiuni este nerecomandat, deoarece analiza de date ar deveni prea complexă. E. 


Fig. 11.5. Colecţia de date pentru un sistem de informaţii medical 
11.42. Schema stea pentru un lanț de supermarket-uri H 
s 


În cele ce urmează vor fi analizate colecțiile de date i i 
meh pentru organizarea unui lan 
Relaţia unu la mulţi poate fi transformată prin atribuirea în entitatea centrală a unui 
identificator compus dintr-un set de identificatori pentru fiecare dimensiune. Fi 
^ jecare tuplu al relaţiei Vânzări are patru coduri: ProdCod, Mark: Proc 
TimpCod, care, luate împreună, formează o cheie primară. E 


Informaţiile despre atributele celor patru domenii sunt următoarele: 
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Produsele sunt identificate de cod (ProdCod) si au ca atribute: Nume, Categorie, 
Subcategorie, Marca, Greutate, Înlocuitor. 

-  Supermarket-urile sunt identificate prin cod (MarketCod) şi au ca atribute: Nume, 
Oraș, Regiune, Zonă, Mărime, Aşezarea supermarketului (de exemplu: la etajul 1 
sau etajul 2, etc.). 

- Promofiile sunt identificate prin cod (PromoCod) şi au ca atribute: Nume, Tip, 
discount procentual (Procentaj), CuponFlag (care indică prezența de cupoane in 
ziare), DataStart, DataSfârșit, Cost si Agenţie de publicitate. 

-Timpul este identificat prin cod (TimpCod) si are atribute ce descriu ziua vânzării 
din timpul săptămânii (ZiS&pt: de duminica până sâmbăta), din timpul lunii 
(ZiLuna: 1 la 31), si din an (ZiAn: 1-365), apoi săptămâna din luna (SáptLuna) si 
din an (SăptAn), apoi luna din an (LunaAn) si Anotimpul. 

În general, dimensiunile prezintă redundanță si date derivate. De exemplu, in 

dimensiunea Timp, cunoscând o zi dintr-un an şi un calendar se pot deriva valori ale tuturor 

atributelor de timp relatate. Similar, dacă un oras apare de mai multe ori în relaţia 

Supermarket, regiunile sale sunt repetate. Redundanfa este introdusă pentru a facilita cât mai 

mult posibil operaţia de analiză de date şi a o face cât mai eficientă. Schema entitate-asociere 

este transformată într-o schemă logică relaţională, rezultatul arătând după cum urmează: 


VÁNZARI(ProdCod, MartetCod. PromoCod, TimpCod, Cantitate, Venit) 
PRODUS(ProdCod, Nume, Categorie, Subcategorie, Marca, Greutate, Inlocuitor) 
SUPERMARKET (MarketCod, Nume, Oraş, Regiune, Zona, Mărime, Aşezare) 
PROMOTIE(PromoCod, Nume, Tip. Procentaj, CuponFlag, DataStart, DataSfársit, 
Cost, Agenţie) 

TIMP TimpCod, ZiSàpt, ZiLună.ZiAn, SáptLunà, SáptAn, LunăAn, Anotimp). 


De fapt, relaţia este in formă normală prin care fiecare atribut care nu este 
cheie depinde funcţional de cheia relaţiei. Pe de altă parte, în general dimensiunile sunt relaţii 
nenormalizate. În final, sunt patru restricţii de integritate între fiecare atribut care alcătuieşte 
cheia tabelei de fapte şi tabelele dimensiune. Fiecare dintre cele patru coduri care alcătuiesc 
cheia tabelei de fapte este o cheie externă, referindu-se la tabela dimensiune care o are ca 
cheic primară. 


11.4.3. Schema fulg de zăpadă 


Schema fulg de zăpadă este o dezvoltare a schemei stea, în care domeniile sunt 
structurate ierarhic. Schema este introdusă pentru a lua în calcul prezența unor dimensiuni 
nenormalizate. Figura 11.6, ilustrează colecţia de date pentru organizarea supermarketurilor, 
reprezentată prin schema fulg de zăpadă. În timp ce dimensiunea promofiilor e neschimbata, 
celelalte dimensiuni sunt organizate ierarhic. Schema fulg de zăpadă prezintă ierarhizări 
explicite, acestea reducând redundanța şi anomaliile, dar fiind mult mai complexă. 

- Dimensiunea Supermarket este structurată după ierarhie: Zonă, Regiune, Oraş, 
Supermarket. Fiecare Zonă include multe Regiuni, fiecare Regiune include multe 
Oraşe si fiecare Oraş are unul sau mai multe Supermarket-uri. 

-Dimensiunea Produs este reprezentată de o ierarhie cu două noi entităţi: Înlocuitor 
şi Categoria Produsului. 
- Dimensiunea Timp e structurată după ierarhia Zi, Lună, An. 
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Atributele schemei stea sunt distribuite unor entităţi variate ale schemei fulg, de 
zăpadă, eliminând sursele de redundantă. Toate relaţiile descrise în figura anterioară sunt “unu 
la multi" şi fiecare element este conectat la unul şi doar un element al nivelului următor. 

Principalul avantaj a schemei stea este simplitatea ei, care permite crearea unei 
interfeţe foarte simple pentru formularea interogărilor. 


Talocuitor fem en Produs fa< >on] Categorie 
- 
D 
n3 
Supermarket «i» Vanzare n» Promotie 
py ON 
— Om e 
Oras zi Lon Dem Luna 
D. an 
ON 
w 
i -a 
Regiune 
4 An 
d 
e 
Zona 


Fig. 11.6 Schema fulg de zăpadă pentru un lanţ de supermarketuri 


11.4.4. Schema constelație de fapte 


Aplicațiile sofisticate pot solicita tabele multiple de fapte care partajează tabele 
dimensiune. O altă variantă a schemei stea este schema constelație de fapte (sau multistea) 
care constă în mai multe tabele de fapte, conectate de obicei la una sau mai multe dimensiuni- 
Acest gen de schemă poate fi văzută ca o colecţie de stele, 

Pentru depozitele de date, schema constelație de fapte este în mod curent utilizată, + 
depozit de date colectând date despre subiecte multiple care se referă la întreaga organiza 
Un exemplu de astfel de schemă poate fi obținut dacă la schema stea iniţială pentru rețeaua d^ 
supermarket-uri se adaugă pe lângă tabela de fapte iniţială, cea de Vânzări, o tal 
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suplimentară de fapte pentru Aprovizionări, care se leagă la rândul ei de dimensiunile 
Supermarket, Produs şi Timp. 
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Fig. 11.7 Schema constelație de fapte pentru un lan de supermarketuri 


11.5. Operații pentru analiza datelor 


În acest paragraf vor fi prezentate interfețele pentru formularea interogărilor şi câteva 
operații utilizate pentru creşterea puterii de exprimarea limbajelor de interogare. 


11.5.1. Interfete de formulare a interogárilor 


Analiza datelor pentru o colecție de date organizate conform schemei stea, necesità 
mai întâi extragerea unui subset de factori şi dimensiuni bazate pe solicitările unei activităţi 
specifice de analiză a datelor. Aceste extrageri de date urmăresc un model standard: 
dimensiunile sunt utilizate pentru a selecta datele şi a le grupa, în timp ce funcțiile agregate 
sunt, de obicei, aplicate faptelor. E posibilă astfel realizarea unor module predefinite pentru 
consultarea depozitului de date în care sunt oferite opțiuni predefinite pentru selecţie, agregare 
şi evaluare a funcțiilor agregate. Figura 11.8 prezintă o interfață de consultare a datelor pentru 
Data Mart-ul din secțiunea 11.4.2. În ceea ce priveşte dimensiunile, acestea sunt preselectate: 
numele promoției, numele produsului, numele vânzării. Pentru fiecare element, sunt selectate 
cantităţile pentru vânzări. Valoarea “Superpromoţie” este inserată in partea de jos a acestui 
identifică o promoţie particulară, indicând astfel procentul din 
loarea vânzărilor obținut prin aceasta. 

În mod similar, sunt selectate “Paste” şi “Ulei” ( pentru produse) pentru intervalul de 


care ar trebui să includă dimensiunile Produs (incluzând valorile selectate Paste si Ulei) și 
Timp (între Februarie şi Aprilie) şi cantitatea totală de vânzări. 


DE 
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Schema 11.52. Drill-down şi roll-up 
ud Analogia cu programele de calcul tabelar nu este limitată la prezentarea datelor. De 
"Superpromotie" Ulei fapt, există două operaţii de manipulare primitivă a datelor care derivă din două operaţii tipice 
Conditie | “Superpromoţie” Paste...Ulei Februarie... Aprilie cu tabele: drill-up şi drill-down (figura 11.10.) 
à Produs.Ni imp. 
= ume. Timp Luna Timp.LunaAn | Produs.Nume | Sumi(Cant) 
Fig. 11.8. Interfața pentru formularea unei interogări OLAP Feb Paste 45K 
Mar Paste 50K 
Interfața corespunde unei interogări SQL cu o structură predefinită, care, este Apr Paste SIK 


completată cu opțiunile introduse de utilizator, În interogare apar clauze join, care conectează 
tabela de fapte cu dimensiunile), clauze de selecție (care extrag date relevante), grupări, 
ordonări, clauze de agregare. 


select DI,CI... DnCn, Ager! (F.C1),... Aggrn(FCn) 
from Fact as F, dimension] as DI... dimensionn as Dn 
where conditie-join (F,D1) 

and 

and conditie-join (F, Dn) and conditie-selectie 


order by DI.CI,...Dn.Cn 


În cazul specificat, interogarea construită conform cu opțiunile utilizatorului arată 
după cum urmează: 


Select Timp. Luna, Produs. Nume, sum(Cantitate) 
From Vânzare, Timp, Produs 

Where Vânzare. TimpCod=Timp. TimpCod And Vânzare. ProdusCod = Produs. ProdusCod 
And Vânzare. PromoțieCod= Promoţie. PromofieCod 

And (Produs. Nume=Paste Or Produs.Nume=Ulei) 

And Timp.LunaAn between “Februarie "and "Aprilie" 
And Promoţie. Nume="Superpromoţie " Group By Timp.LunaAn, Produs.Nume 
Order By Timp. LunaAn, Produs.Nume 


Rezultatul interogării poate fi prezentat de clientul OLAP în forma de matrice sai 
grafic. În formatul matrice, dimensiunile corespund rândurilor si coloanelor, iar faptele 
corespund celulelor, ca în figura 11.9. T 

Această reprezentare a datelor este destul de des utilizată de uneltele de analiză 
deoarece permite operaţii de calcul tabelar asupra rezultatelor interogărilor. Graficele clasice. 
cu bare si cele tip “plăcintă” pot fi utilizate pentru vizualizarea datelor; de exemplu graficele 
cu bare pot utiliza diferite culori pentru a reprezenta diferite tipuri de produse la diferite 
momente de timp. E 


[Fe | Mar * 
Uii [5K [5K 
Pase |45K | 50K. 


Fig. 11.9. Rezultatul interogării OLAP 
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Fig. 11.10. Subseturi de rezultate ale interogării OLAP 


Drill-down permite introducerea unei dimensiuni a analizei, realizând astfel o 
dezagregare a datelor. De exemplu, un utilizator ar putea fi interesat de adăugarea distribufici 
cantităţii vândute pe zone de vânzare, realizând operația drill-down pe Zonă. Presupunând cà 
atributul Zona ia valoarea „Nord”, „Centru” si „Sud”, obținem tabelul din figura 11.11. 


Timp.LunaAn | Produs.Nume | Sum(Cant) 
Feb Paste 18K 
Feb Paste 15K 
Feb Paste 12K 
Mar Paste 18K 
Mar Paste 18K 
Mar Paste 14K 
Apr Paste IK | 
Apr Paste VK | 
Apr Paste 1éK | 


Fig. 11.11. Drill-down pentru tabelele reprezentate în figura 11.10. 


Roll-up permite in schimb eliminarea unei dimensiuni de analiză, reagregánd datele. 
De exemplu, un utilizator poate să decidă că subdivizarea vânzărilor pe zone e mai folositoare 
decât cea pe luni. Acest rezultat e obținut realizând o operaţie de roll-up pe luni, obținându-se 
rezultatul afişat în figura 11.12. 

Alternând operaţiile roll-up si drill-down, analistul poate evidenția dimensiunile care 
au influență mai mare asupra fenomenelor reprezentate de fapte. De notat cà operaţia roll-up 
se realizează operând pe rezultatul interogării, în timp ce operaţia drill-down necesită in 
general o reformulare şi o reevaluare a interogării pentru că necesită adăugarea unei noi 
coloane în rezultatul interogării. 


Produs.Nume Zona Sumi(cant) 
Paste Nord 54K 
Paste Centru 50K 
Paste Sud 42K 


Fig. 11.12. Eliminarea tabelelor prezentate în figura 11.11. 
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11.5.3. Secţiuni şi rotații 


Asupra cuburilor de date trebuie să se poată predefini viziuni sau imagini (views) 
specifice diverselor categorii de utilizatori, prin operaţii de secfionare. O secțiune (slice) 
reprezintă un membru specific al unei dimensiuni, de ex. Produsul A din dimensiunea Produs. 
Sectionarea conduce la crearea unei serii de intersecții cu alte dimensiuni pentru secţiunea 
respectivă. De exemplu, după lună, după regiune, după client. Acest “după” ne indică cum 
putem realiza vizualizarea datelor prin limitarea unor atribute la anumite valori şi obținerea 
unui cub de date redus (procedeu numit data dicing). Aceasta intersecție multidimensionalà si 
modul ei de organizare face modelul OLAP foarte puternic. Abilitatea de a schimba 
perspectivele asupra datelor intuitiv si instantaneu este o facilitate de bază a tuturor 
instrumentelor serioase pentru OLAP. 

Alte două facilităţi importante în proiectarea multidimensională OLAP sunt pivorarea. 
şi imbricarea dimensiunilor. Pivotarea presupune schimbarea intre ele a dimensiunilor in 
cadrul unei vizualizari, reorientarea cubului de date, de obicei trecerea de pe linii pe coloane 
si invers. Imbricarea presupune detalierea dimensiunii imbricate pentru fiecare valoare a 
dimensiunii care o conţine. 


11.5.4. Data cube 


Utilizarea recurentă a agregărilor a sugerat introducerea unui operator foarte putemic, 
cunoscut ca DATA CUBE, pentru a realiza toate agregările posibile prezente într-o tabelă 
extrasă pentru analiză. Pentru descrierea operatorului se va folosi un exemplu. Se presupune 
că depozitul de date conține următoarea tabelă care descrie vânzările de maşini. Vor fi afişate 
tuplurile unice referitoare la mașini Ferrari sau Porsche roşii, vândute între 2006 si 2007 
(figura 11.13). 


Culoare | Vânzări 


Producător 


Fig. 11.13. Imaginea unei tabele de vânzări 


DATA CUBE este construit prin adăugarea clauzei cu WITH CUBE la o interogare ce 
confine o clauză GROUP BY, De exemplu, se consideră următoarea interogare: 


select Producător,4n,Culoare,Sum(Vânzări) 
from Vânzări 

where (Producător=" Ferrari” or Producător = 'Porsche ) 
and Culoare= Roşu and An between 2006 and 2007 
group by Producător, An, Culoare with cube 


Interogarea extrage toate agregările construite prin gruparea intr-un mod combinat * 
tuplurilor conform cu cele trei dimensiuni ale analizei (Producător, An, Culoare). Agregarc* 
este reprezentată de valoarea polimorfică ALL care (ca şi NULL) e prezentă în toat 
domeniile si corespunde tuturor valorilor posibile prezente in domeniu ( figura 11.14). 
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O reprezentare spaţială a structurii DATA CUBE este evidezie în £g—s 11.14. 
Diagrama arata un spaţiu cartezian construit pe trei axe corespunzână ăomeniilcr celor r= 
atribute. În acest exemplu, domeniul Producător ia valorile Ferrari si Porsche, doreciul Az îs 
Bpalorte 2006 si 2007, iar domeniul Culoare ia valoarea Roşu. Punctele în spei: zeprez=ză 
frega etui, t da pam mur ta cde d phai cz dace. În 
exemplul considerat, trei din patru sunt prezente. Cele trei planuri 


“spaţiu cu n dimensiuni este iti în cazul unei operaţii de DATA UBE am 
F arbitrar de atribute de grupare. 


Producător | An | Culoare | Suma(Vánzári) - 

Ferrari |2006| Rosu 50 

Ferrari [2007 | Roşu 85 

E Ferrari |2006| All 50 
1 Ferrari |2007| All 85 
t Ferrari | AU | Roșu 135 
H Ferrari | AU | All 135 
Porsche |2006| Roşu 80 

Porsche |2006| Al 80 

Porsche | All | Roşu 80 

Porsche | Al | All 80 

All  |2006| Roşu 130 

All  |2007| Roşu 85 

All All | Roşu 215 

AL  |2006| All 130 

AU 2007 | Au 35 

All AU | AI 215 


Fig. 11.14. Operația data CUBE a tabelei reprezentate în figura 11.13 


„Complexitatea DATA CUBE creşte exponențial cu creşterea pan de arid 
‘care sunt grupate. O extensie diferită de SQL construieşte agregări px în los si 
construiască toate agregările posibile; astfel complexitatea evaluării EE ope: 
doar într-un mod liniar cu creşterea numărului de atribute grupate. Această extensie neces 3 
înlocuirea clauzei WITH CUBE cu clauza WITH ROLL-UP, ilustrată in uzmătorul exempt: 


select Producător, An, Culoare, Sum(Vânzări) 
from Vânzări 

here (Producător= 'Ferrari' or Producător= "Porsche ) 
Tand Culoare ="Roşu” 

„and An between 2006 and 2007 

„Pow By Producător, An, Culoare with roll-up 

|i Rezultatul evaluării acestei interogări este evidențiat în Figure 11.15. Se obsenă 
Progresul agregărilor, de la stânga la dreapta, şi faptul că rezultatul are mai puține up: 
decăt rezultatul operaţiei DATA CUBE. 
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adis 


Fig. 11.15, Roll-up realizat asupra tabelei reprezentate în figura 11.13 


Interogările cu WITH CUBE şi WITH ROLL-UP sunt prezente în multe SGBD-uri 
relafionale si nu necesită în mod obligatoriu prezența unui depozit de date. În orice caz, o 
interpretare a celor două interogări conform modelului stea este întotdeauna posibil 
deoarece atributele clauzei GROUP BY joacă rolul domeniilor, în timp ce atributele rămase 
ale clauzei SELECT descriu operaţiile de agregare aplicate faptelor. 


11.6. Dezvoltarea depozitului de date 


Există patru abordări alternative cu privire la dezvoltarea depozitului de date: 

- Prima abordare constă în utilizarea tehnologiei relaționale, adaptată si extinsă 
corespunzător. Datele sunt stocate utilizând tabele, dar operaţiile de analiză sunt 
realizate în mod eficient utilizând structuri speciale de date. Acest tip de sistem 
este numit ROLAP (Relational OnLine Analytic Processing). În ROLAP toate 
agregările sunt stocate în cadrul bazelor de date relaționale sursă. ROLAP 
reprezintă cea mai lentă soluție pentru consultarea datelor, deoarece, indiferent 
dacă există sau nu o agregare, trebuie accesat direct depozitul de date. Această 
soluţie este recomandată doar pentru implementări de dimensiuni mai mici. 


ză 
* A doua abordare, mai radicală, constă în stocarea datelor în formă 
multidimensională, folosind structuri de date vector. Acest tip de sistem este numit 
MOLAP (Multidimensional OnLine Analytic Processing). În MOLAP, atât datele 
sursă cât şi agregările sunt stocate în format multidimensional. MOLAP este 
opțiunea cea mai rapidă pentru consultarea datelor, dar necesită cel mai mult spaţiu, 
de disc (acest criteriu nu mai reprezintă o prioritate in ultima vreme, având 
vedere scăderea costurilor de stocare şi procesare). 


- HOLAP (Hybrid OnLine Analytic Processing) este o combinaţie a primelor două . 
modele, Bazele de date HOLAP stochează ile existente într-o 
multidimensională, lăsând nivelul celulelor de bază în formă relaţională. 
datele sunt în formă preagregată, HOLAP oferă performanțele MOLAP 
când este nevoie de preluarea datelor din tabele. 

- DOLAP (Desktop OnLine Analytic Processing) presupune stocarea datelor 
maşini desktop individuale, fiind întâlnite in aplicații de dimensiune redusă, 
care există solicitări minime ca mai mulţi utilizatori să aibă acces la o bază de 
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centrală aflată pe un server central. DOLAP este inclusă în soluțiile oferite de 
mulți dintre furnizori pentru a facilita analiza în cazurile în care utilizatorii nu se 
pot conecta la rețeaua companiei. 


Soluţia MOLAP este adoptată de un mumăr mare de produse specializate in 

tul Data Mart-urilor, datorită restricţiilor legate de hardware şi de costul 

ii. HOLAP oferă performanţe mai bune în cazul in care se accesează o bază de date 

sand-alone. Soluţia ROLAP este utilizată de un numâr mare de producători de soluţii 

relaţionale. Aceasta adăuga soluţii specifice OLAP experienței tehnologice a SGBD-urilor 

reafionale şi astfel este foarte probabil ca ROLAP să reziste pe termen mediu şi lung. 

Soluţiile ROLAP sunt preferate când cererile de interogare sunt relative reduse şi se accesează 

o baza de date stand-alone. În orice caz, tehnologiile ROLAP şi MOLAP utilizează soluţii 
inovative pentru acces la date și cu privire la indecsi şi materializarea view-urilor. 

Aceste soluţii iau în considerare faptul că depozitul de date este folosit în principal 
pentru operaţii de citire şi încărcare iniţială sau progresivă a datelor, în timp ce modificările şi 
anulările sunt rare. Depozitele de date mari utilizează paralelismul, cu fragmentarea şi 
alocarea corespunzătoare a datelor pentru a face interogările mai eficiente. În cele ce urmează 
se vorbeşte doar despre tehnologiile ROLAP. 


11.6.1. Indecsi de bitmap si indecsi de join 


Indecyii de bitmap permit crearea eficientă a conjuncţiilor si disjunctiilor in condiţii de 
selecţie sau a operaţiilor algebrice de reuniune şi intersecţie, Acestea sunt bazate pe ideea de 
a reprezenta fiecare tuplu ca un element al unui vector de biţi. Lungimea vectorului este egală 
cu cardinalitatea tabelului. În timp ce nodurile rădăcină și nodurile intemerdiare ale indecsilor 
tanii de biți rămân neschimbaji, “frunzele” indecsilor conţin câte un vector pentru fiecare 
valoare a indexului. Biţii din vectori sunt setaji pe valoarea 1 pentru tuplurile care au acea 
valoare și 0 altfel. 

Se presupune, de exemplu, realizarea unui index de bitmap pe atributele Nume si 
Agenţie ale tabelei Promoţie descrise în secțiunea 11.4.2. Pentru a identifica tuplul 


accesarea separată a celor doi vectori 
"Promoplus" folosind indecși, extragerea si folosirea lor “bit cu bit”, Vectorul rezultat va 
conține 1 pentru tuplurile care satisfac condiţia, care sunt astfel identificate. Operaţiile 
similare pe bit permit managementul disjuncțiilor (figura 11.17.) 

Operajile pe biţi sunt foarte rapide, dar, evident, un index bitmap este greu de 
administrat în cazul în care tabela este supusă modificărilor. Este convenabil ca acesta să fie 
construit în timpul operaţiilor de încărcare a datelor pentru o cardinalitate dată a tabelei. 


Indecşii join permit execuţia eficientă a reuniunii dintre tabelele dimensiune si 
tabelele de fapte. Ei extrag acele fapte care satisfac condiţiile impuse de dimensiuni. Indecsii 
join sunt construiți pe dimensiune cheie, “frunzele” lor în loc să lege tuplurile dimensiunilor, 
leagă tuplurile tabelei de fapte care conţin acele valori cheie. Referindu-ne din nou la Data 
Mart-urile din secţiunea 11.4.2, un index join asupra atributului PromoCod va contine în 
"frunzele" sale referinţe la tuplurile de fapte fiecărei promoții. De asemenea, 
este posibil să construim indecsi de join pe seturi de chei ale diferitor dimensiuni, de exemplu: 


şi 
Ca de obicei, în cadrul proiectării fizice, utilizarea indecsilor de bitmap şi de join este 
legată de beneficiul cu privire la costul analizei. Costurile sunt esențiale în ceea ce priveşte 


necesitatea construirii şi stocării indecşilor în mod permanent și beneficiile sunt 
utilizarea actum da către sistemal depozitull de date pentra ez ac iara Ie de 


Trei 
Prom | Nume Nr | pe | Capon | super. 
Agentie | | inreg | Două | 15% lie 
T Treipt == 
Promo- 
PL | Doua | Piti 1 1 o 3i x 
Cupon 
Xr dee | Se 2| 1 v 
2 
Pa | Super. | Promo- 5 
song. phs d d E 
P* | Promo- [ji 
P4 | Două ed 4 1 o 9 
Cupon 
w "ume [oem 
a. s| o 1 o 


Fig. 11.17. Utilizarea indecsilor de bitmap 


11.6.2. Materializarea view-lor 


Multe interogări ale depozitului de date necesită repetate agregüri si si i 

În acest caz, este convenabilă evaluarea view-lor care siot tóc drei iq 
permanentă. Această tehnică este numită materializarea view-lor. De exemplu, în colecţia de 
date cu privire la organizarea supermarketurilor, un view materializat poate confine datele 
vânzărilor agregate pe produs, sau vânzările lunare pe fiecare magazin. Interogările despre 
aceste agregări sunt realizate în mod direct în materializarea view-lor, în loc să fie realizate in 
depozitul de date. Alegerea view-lor materializate este o problemă destul de complexă, care 
NOS cunoaşterea interogărilor realizate în mod curent într-un Data Mart si frecvenţa lor de 

ie. 

În general, un view materializat este convenabil atunci când în mod 
sensibil timpul de execuţie al unor interogări utilizate frecvent. hern y pes 
convenabilă într-un mediu ca depozitul de date, în care tabelele de bază nu sunt modificate in 
mod continuu. Când tabelele sunt modificate in mod corespunzător sau reincárcate, view-le 
trebuie oricum actualizate, propagând efectele modificărilor asupra tabelelor de bază. 
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12.1. Introducere în data mining 


Termenul de „data mining” este folosit pentru a caracteriza tehnicile de căutare 
pime pentru informațiile ascunse în datele dintr-un depozit de date. Data mining este 

it pentru studii de piață, de exemplu identificarea articolelor cumpărate împreună sau 
Sonsecutiv, aceasta pentru a optimiza amplasarea de bunuri pe rafturile unui magazin sau 
Trimiterea selectivă de materiale cu caracter promoțional. Alte aplicații frecvent întâlnite sunt 
tnaliza comportamentală (de exemplu, căutarea de fraude si folosiri ilegale ale cardurilor de 


edit) si realizarea de previziuni bazate pe serii istorice (de exemplu, cele referitoare la 
tratamente medicale). Data mining are caracter interdisciplinar folosind nu numai tehnologia 
de organizare a datelor, dar şi statistica (pentru definirea calităţii sau observarii) si inteligența 
arificială (în procesul de descoperire a cunoştinţelor generale din date). 
I. — Modelele identificate cu astfel de metode pot oferi unui analist de date, puncte de 
neaşteptate şi folositoare care pot fi investigate ulterior mai atent, poate utilizând 
eventual instrumente suport de decizie. În acest capitol, vor fi discutate câteva aplicaţii de 
(data mining pentru fiecare din acestea existând unelte comerciale disponibile de la marii 
producători, Importanţa acestui domeniu creşte tot mai mult odată cu trecerea timpului odată 
ta dezvoltarea si răspândirea instrumentelor de data mining. În ultima vreme, data mining a 


[uid o popularitate crescândă şi a condus la obţinerea unui avantaj competitiv pentru multe 


E ^ Cea mai importantă caracteristică ce diferențiază data mining de subdomenii ale 
statisticii sau inteligenței artificiale este aceea că volumul de date este foarte mare; desi idei 
än aceste subdomenii sunt aplicabile la problemele din data mining, scalabilitatea în raport cu 
dimensiunea datelor este un criteriu important în plus. 

È Un algoritm este scalabil dacă timpul de rulare creşte (liniar) în proporție cu mărimea 
setului de date, depinzând de resursele disponibile ale sistemului (de exemplu, cantitatea de 
memorie principală şi de hard disk disponibilă). Vechii algoritmi trebuie adaptati sau trebuie 
dezvoltați noi algoritmi pentru a asigura scalabilitatea . 

- —— Gäsirea de trenduri utile în seturile de date este o definiţie mai largă a data mining. 
ltr-un sens se poate crede că interogările din bazele de date fac deja acest lucru. Într-adevăr, 
îvem o analiză continuă si instrumente de explorare cu interogări SQL pe de o parte, OLAP in 

“mijloc, sí tehnicile de data mining pe de altă parte. 

7  "interogürile SQL sunt construite folosind algebra relațională (cu unele extensii). 

and permite interogări de un nivel mai înalt bazate pe modele de date multidimensionale, 

data mining oferă operaţiile de analiză cele mai abstracte. Ne putem gândi la diferite 
ini în data mining ca la interogări complexe, specificate la nivel înalt, cu câțiva parametri 
se pot defini de utilizatori si pentru care sunt implementaţi algoritmi specializaţi. 
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În lumea reală, data mining este mult mai mult decât simpla aplicare a unuia din aces; 
algoritmi. Datele sunt deseori incomplete sau cu zgomot şi dacă acest lucru nu este înţeles şi 
corectat, este foarte posibil ca multe modele să fie ratate, iar modelele detectate să nu fie 
relevante. În continuare, analistul trebuie va decide la ce fel de algoritmi va apela, si îi va 
aplica unui subset de modele de date si variabile bine ales, va analiza rezultatele si va aplica 


condus la o sporire a profitului. Calitatea regulilor de asociere poate fi exact măsurată. 

Pesupundnd că un grup de tupluri constituie o observație, putem spune cà observația satisface 

isa unei reguli dacă ea conţine cel puţin un tuplu pentru fiecare articol. Pot fi definite 
jroprietățile de suport şi încredere. 


alte instrumente suport de decizie şi de , întregul proces repetându-se.. T Data. Bunuri 
I ini cage i 1 17/12/98 | Pantaloni-schi 

Procesul de data mining 1 17/12/98 | Ghete 
2 18/12/98 | Tricou 

Obiectivul data mining este extragerea informaţiei utile din seturi mari de date, Acest „LA 18/12/98 | Geacă 

lucru este realizat în mod iterativ, prin adaptări succesive, realizându-se o extragere 2 18/12/98 | Ghete 
progresivă a cunoştinţelor (Knowledge Data Discovery process - KDD), care este divizată în 3 18/12/98 | Geacă 
patru faze: 4 19/12/98 | Geacă 
- Explorarea domeniului: extragerea de informații utile este imposibilă dacă nu se 4 19/12/98 | Tricou 


realizează o bună înțelegere a domeniului de aplicații în care se lucrează. 
- Pregătirea setului de date: acest pas necesită identificarea unui subset de date ale 
depozitului de date pentru care se va realiza data mining. Este de asemenea 
necesară o codificare a datelor pentru a le transforma în intrări corespunzătoare 

pentru algoritmul de data mining. 

- Descoperirea de modele: aceasta constà în aplicarea tehnicii de mining pe setul de 

date extras mai devreme pentru a descoperi modele repetitive în date, 

- Evaluarea modelelor: aceasta constă în obținerea concluziilor în urma descoperirii 
modelelor, evaluând ce experimente vor trebui analizate şi ce ipoteze vor trebui 
formulate şi ce consecinţe rezultă în procesul de descoperire a cunoştinţelor! 
Rezultatul oricărui pas în procesul KDD poate conduce la un pas anterior pentru a 
reface procesul folosind noile cunoștințe câștigate, 


Fig. 12-1. Baza de date pentru analiza coșului de cumpărături 


Suportul reprezintă acea parte a observaţiilor care satisfac atât premisa, cât şi 
A ME Bre] reprezintă o parte a observaţiilor care satisfac consecința dintre acele 
m due suportul măsoară importanța unei reguli (cât de des premisa şi consecinţa sunt 
prezente), în timp ce încrederea măsoară siguranța (dată fiind premisa, cât de des este 

Pelea dia mining referitoare a descoperirea regulilor de asociere poate fi enunțată 
asfel: să se găsească toate regulile de asociere cu suportul mai mare decât o anumită valoare. 
De exemplu, figura 12.2 prezintă reguli de asociere cu suport și încredere ridicate, mai mari 
sau egale cu 0.25. Dacă, pe de altă parte, interesează numai de regulile care au suportul şi 
încrederea mai mari de 0.4, trebuie extrasă regula “geacă-tricou” şi * tricou-geacă”. 

Există variante ale acestei probleme, obținute folosind diferite extrageri de date, dar 
cu aproximativ același algoritm. De exemplu, găsirea produselor vândute împreună şi în 
aceeași promoție sau produse vândute împreună doar dacă au fost aranjate împreună. a 
Alte variante ale aceleiaşi probleme, ce necesită un algoritm diferit, permit studiul unor serii 
dependente de timp referitoare la vânzări, de exemplu, marfa vândută consecutiv aceluiaşi 
client. De obicei, sunt folosite pentru organizarea de campanii promoționale sau expedierea de 
materiale publicitare. 


12.1.2. Probleme de data mining 


Chiar dacă fiecare aplicaţie are trăsături specifice, există probleme generale care au o 
structură repetitivă regulată. Aceste probleme pot fi formalizate și apoi rezolvate de o gamă de 
algoritmi de data mining. De obicei, algoritmii de data mining sunt caracterizați de o bună 
scalabilitate, ceea ce garantează caracteristici de eficiență ridicate când sunt aplicate pe seturi _ 
mari de date. Vor fi luate în considerare trei probleme clasice: y 

l. Descoperirea de reguli de asociere. x 


| Consecința 


toate tuplurile si este folosit pentru a grupa toate tuplurile ce formează o achiziţie. Regulile 
descoperă situații i care prezența unui articol într-o tranzacție este legată de prezenţa sti 
articol cu o probabilitate ridicată (figura 12.1.) K. 
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Regulile de asociere si căutarea de modele, permit si studiul altor probleme dincolo de 

“analiza coșului de cumpărături”, De exemplu, în medicină se poate evidenția ce rezistență la 

antibiotice este simultan prezentă într-o antibiogramă, sau dacă disbeticii vor suferi o 
deteriorare a vederii în termen de zece ani după descoperirea bolii. 


2. Discreditarea. Este o etapă tipică în pregătirea datelor care permite reprezentarea 


unui interval continuu de valori folosind câteva valori discrete, pentru a face 
fenomenul mai uşor de vizualizat. De exemplu, valorile tensiunii arteriale pot f 
descrise simplu de trei clase: “ridicată”, “medie” și “joasă” şi această operaţie 
poate permite cu succes corelarea unei valori a presiunii sângelui cu o inghifire a 
unei pastile. 


. Clasificarea. Arc ca scop catalogarea unui fenomen într-o clasă predefinită 
Fenomenele sunt de obicei prezentate sub forma unor înregistrări elementare ale 
observaţiei (tupluri). Clasificatorul este un algoritm care realizează clasificarea. 
Este construit automat, folosind un set predefinit de date de antrenare ce constă 
dintr-un set de fenomene deja clasificate, apoi este folosit pentru clasificarea unor 
fenomene generice. De obicei, clasificatorii sunt prezentaţi sub forma unor arbori 
de decizie în care nodurile sunt etichetate prin condiţii care permit luarea 
deciziilor. Condiţia se referă la atributele relaţiei care înregistrează fenomenul 
Când fenomenele sunt descrise de un număr mare de atribute, clasificatorii au și 
responsabilitatea de a selecta câteva atribute semnificative, separându-le de cele 
nerelevante. Se doreşte clasificarea polifelor unei companii de asigurări, atribuind 
fiecăreia un risc înalt sau scăzut. Pornind de la o colecţie de observaţii care descrie 
polifele, clasificatorul determină iniţial faptul că atributele semnificative pentru 
definirea riscului unei polite sunt doar vărsta şoferului si tipul vehiculului. Acesta 
construieşte apoi un arbore precum cel prezent in figura de mai jos. Un risc inst 
este atribuit tuturor şoferilor sub vărsta de 23 de ani sau şoferilor care conte 
maşini sport sau camioane (figura 12.3.). 


Poliţa (vârstă, număr, tipauto) 
Agec23 
F 


Tipauto-"sport" 


e ^ e 


Fig. 12.3. Clasificatorul pentru identificarea riscurilor polifei 


e 
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Sc consideră problema numărării obiectelor care apar concomitent, aceasta fiind 
tă de probleme cum este analiza coşului de cumpărături. Coşul de cumpărături este o 
de obiecte cumpărate de un client intr-o singura tranzacţie (o singură vizită la 
vin, o singură comandă prin poştă, sau o singură comandă la un magazin virtual pe 
net). Un obiectiv frecvent pentru vânzători cu amănuntul este de a identifica obiecte care 

achiziţionate împreună. Această informaţie poate fi folosită pentru a îmbunătăţi 
ea ofertei de bunuri într-un magazin, sau ofertei din paginile unui catalog (figura 


Fig. 12.4. Relaţia „Achiziţii” pentru analiza costului de cumpărături 


1. Seturi de obiecte frecvente 


, Relaţia “Achiziţii” prezentată în tabelul de mai sus va fi folosită pentru a ilustra 
e de obiecte frecvente. 
Înregistrările sunt sortate în grupuri de o tranzacţie. Toate tuplurile dintr-un grup au 
E E ERE inot remarca 


gg agrar pret apa ANR E III Gc at 
împreună cu cantitatea cumpărată. Se observă că există o redundanfá in 
poate fi descompusă prin păstrarea ilor “Idtranz-ldelient" separat si 
d la Idclient; acesta ar putea fi chiar modul în care datele sunt stocate. Oricum, este 
ie = dorea MAS Cue. Mi SEN rele pene 
seturile de date frecvente. Crearea de astfel de tabele “denormalizate” 
Procl de dui minta pă veac în perl de oxkdju 4 afis i tă 
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Prin examinarea grupurilor de seturi de tranzacții în “Achiziţii” se pot face observați 
de forma: “În 75% din tranzacții si stilourile si cerneala sunt achiziţionate împreuna”. Este o 
declaraţie care descrie tranzacţiile în baza de date. Extrapolarea la tranzacţii viitoare trebuie. 
făcută cu grijă. = 

Analiza cogului de cumpărături implică utilizarea unei terminologii specifice. Prin sep 
de obiecte se înţelege un grup de obiecte. Suportul unui set de obiecte este acea parte a 
ai caii din baza de date care conţine toate obiectele din setul de obiecte. F 

in exemplul analizat, se va considera setul de obiecte (stilou, cerneală) si se observa 
că suportul acestui set de obiecte a fost de 75% în “Achiziţii”. Se poate concluziona cà | 
stilourile şi cerneala sunt frecvent achiziţionate împreună. | 

Dacă se consideră setul de obiecte (lapte, suc) suportul este de doar 25%. Rezultă că — | 
laptele şi sucul sunt cumpărate rar împreună. $ 

De obicei, numărul seturilor de obiecte care sunt cumpărate frecvent împreună este 
relativ mic, în special când mărimea setului de obiecte creşte. Prezintă interes toate seturile de 
obiecte al căror suport este mai mare decât un suport minim predefinit de utilizator, numit 
"minsup". Aceste seturi se numesc seturi de obiecte frecvente. De exemplu, dacă suportul 
minim este setat la 70% atunci seturile frecvente din exemplu considerat sunt {stilou}, 
(cernealà), (lapte), (stilou,cerneală) şi (stilou, lapte). Prezintă interes si seturile de obiecte 
care conţin doar un singur obiect, deoarece identifică obiectele frecvent cumpărate. 

În continuare, va fi prezentat un algoritm pentru identificarea seturilor de obiecte 
frecvente. Acest algoritm se bazează pe o proprietate fundamentală simplă a seturilor de 
obiecte frecvente: 

Proprietate a priori: Fiecare subset al unui set de obiecte frecvente trebuie sa fie un 
set de obiecte frecvente. -— 

Algoritmul este iterativ, identificând mai întâi seturile de obiecte frecvente cu doar un 
obiect. În fiecare iterajie consecutivă, seturile de obiecte frecvente identificate în iteraja 
anterioară sunt extinse cu alte obiecte pentru a genera seturi candidate de obiccte mai mari. 
Considerând numai seturile de obiecte obţinute prin lărgirea setului de obiecte frecvente, se va 
reduce foarte mult numărul de seturi de obiecte frecvente candidate; această optimizare este 
crucială pentru execuţia eficientă. 

Proprietatea a priori garantează că optimizarea este corectă, asta dacă nu se ratează 
nici un set de obiecte frecvente. 

O singură scanare a tuturor tranzacţiilor (relaţia “ Achiziţii”) este suficientă pentru a 
determina care dintre seturile de obiecte candidate generate într-o iteraţie sunt seturi de 
obiecte frecvente. Algoritmul se termină atunci când în cadrul unei noi iterații nu mai este 
identificat nici un set de obiecte frecvente (figura 12.5.). Lr 


pentru fiecare obiect, Nivel 1 i 
verifică dacă este un set de obiecte frecvent //apare în > minsup z 
kel > 
repeta // Iterativ, identificarea în funcţie de nivel setului de 
obiecte frecvente E. $ 

pentru fiecare set de obiecte frecvente nou I, cu k obiecte, 2n 


generează toate seturile de obiecte 1,,, cu k*1 obiecte, I, C Ipa 
scanează toate tranzacţiile odată şi verifică dacă seturile cu k+ 1 obiecte sunt 
frecvente 
k=k+l 
până când nu mai este identificat nici un set nou de obiecte frecvente 


i 


Fig. 12.5 Algoritm pentru aflarea seturilor de obiecte frecvente. 
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Algoritmul va fi ilustrat pentru relaţia Achiziţii de mai sus, cu minsup setat la 70%. În 
prima iteraţie (Nivelul 1) va fi scanată relația “Achiziţii” şi se va determina ca fiecare din 
aceste seturi de obiecte dintr-un singur obiect este un set de obiecte frecvent: (stilou), apare 
în toate cele patru tranzacţii, (cerneală), (apare în trei tranzacţii din patru), iar (lapte ) (în trei 
in patru). 

a doua iteraţie (Nivelul 2) se extinde fiecare set de obiecte frecvent cu un obiect 

adiţional şi se generează următoarele seturi de obiecte candidate (stilou, cerneală), (stilou, 
lapte), (stilou, suc), (cerneală, lapte) şi (lapte, suc). Prin scanarea relaţiei “Achiziţii” din 
nou, se determina că apar următoarele seturi de obiecte frecvente: (stilou, cerneală) si (stilou, 
lapte). 
ES În a treia iteraie (Nivelul 3) se extind seturile de obiecte candidate (stilou, cerneală, 
lapte}, (stilou, cerneală, suc) și (stilou, lapte, suc). Se observă că (cerneală, lapte, suc) nu 
este generat. O a treia scanare a relaţiei “Achiziţii” ne ajută să determinăm că niciunul dintre 
aceste seturi de obiecte nu este frecvent. 

Algoritmul simplu prezentat aici pentru găsirea seturilor de obiecte frecvente 
ilustrează principalele caracteristici ale unor algoritmi mai sofisticafi, şi anume generarea și 
testarea iterativă a seturilor de obiecte candidate. Se va lua în considerare o rafinare 
importantă a acestui algoritm simplu. Generarea seturilor de obiecte candidate prin adăugarea 
unui nou obiect la un set despre care se stie că este un set de obiecte frecvente este o încercare 
de a limita numărul seturilor de obiecte candidate folosind proprietatea a priori. Aceasta 
implică faptul că un set de obiecte poate fi frecvent, daca toate subseturile sale sunt frecvente, 
Deci, numărul seturilor de obiecte candidate poate fi redus înainte de scanarea bazei de date 
"Achizigii" prin verificarea dacă toate subseturile unui set de obiecte candidat nou generat 
sunt frecvente. Doar dacă toate subseturile a unui set de obiecte candidate sunt frecvente se 
va calcula suportul prin scanarea bazei de date. Comparat cu algoritmul simplu, acest algoritm 
rafinat generează mai puţine seturi de obiecte candidate la fiecare nivel și acest lucru reduce 
cantitatea calculelor în timpul scanării bazei de date “Achizi| 

Se consideră algoritmul rafinat pentru tabela “Achiziţii”, cu minsup = 70%. În prima 
iterajie (Nivelul 1) se determină frecvenţa seturilor de obiecte de mărimea unu: (stilou), 
(cerneală) si (lapte). În a doua iteraţie (Nivelul 2), numai următoarele seturi de obiecte 
candidate rămân la scanarea tabelei “Achi (stilou, cerneală), (stilou,lapte), şi (cerneală, 
lapte). Deoarece (suc) nu este frecvent, nici seturile de obiecte (stilou, suc), (cerneală, suc) 
şi (lapte, suc) nu pot fi frecvente si se vor elimina aceste seturi de obiecte a priori, fără a le 
considera în timpul scanării relaţiei “Achiziţii”. În a treia iterafie (Nivelul 3), nu este generat 
nici un set de obiecte candidat. 

Deci, setul de obiecte (stilou, cerneală, lapte) nu pot fi frecvent dacă subsetul său 
(cerneală, lapte) nu este frecvent. Astfel, versiunea îmbunătăţită a algoritmului nu necesită o 
a treia scanare a tabelei “Achiziţii”. 


12.2.2. Interogările iceberg 


Se consideră din nou tabela “Achiziţii”. Se doreşte găsirea de perechi de clienți şi 
produse în aşa fel încât clientul să fi cumpărat produsul de cel puţin cinci ori. Această 
interogare poate fi exprimată în SQL astfel: 


Select A.Ldclient, A. Produs, sum(A.Cantitate) From Achiziţii A Group By A.ldclient A. Produs 
Having sum (A. Cantitate) >5 
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Să presupunem că această interogare ar fi evaluată de un SGBD relafional. Pentru 
fiecare pereche (Idelient, Produs), trebuie verificat dacă suma câmpului Cantitate este maj 
mare decât 5. O abordare posibilă este de a face o scanare asupra relaţiei “Achiziţii” şi de a 
relua calcularea sumei pentru fiecare pereche (Idclient, Produs). Aceasta este o strategie de 
execuție fezabilă atâta timp cât numărul perechilor este îndeajuns de mic ca să încapă în 
memoria principală. Dacă numărul de perechi este mai mare decât memoria principală, 
she să fie utilizate alte modalităţi de evaluare a interogărilor, care implică fie sortare, fie 

hing. i 

Chiar dacă relația “Achiziţii” este foarte mare si numărul de grupuri (ldclient, Produs) 
poate fi uriaş, rezultatul interogării va fi probabil relativ mic din cauza condiţiei din clauza 
“Having”. Doar grupurile în care clientul a cumpărat produsul de mai mult de cinci ori apar 
în output. De exemplu, sunt nouă grupuri în interogarea relației “Achiziţii”, deși output-ul 
contine trei înregistrări. Numărul de grupuri este foarte mare, dar răspunsul la interogare - 
vârful icebergului - este, de obicei, foarte mic. Deci, o astfel de interogare este denumită 
interogare iceberg. În general, având o schemă relaţională R, cu atributele AJ, 42,...Ak, i B 
şi o funcție agregatà agr, interogarea iceberg are următoarea structură: 


Select RAI, R.A2,...R.Ak, aggr (R.B) From Relatia R Group By R.A1,...R. Ak 
Having aggr(R.B) >=constantă 


Modalităţile tradiţionale de realizare ale interogărilor calculează întâi valorile funcţiei 
de agregare pera teme grupurile i elimină grupurile care mu satisfac condiţia în clauza 

Comparând interogarea cu problema de a găsi seturile de obiecte frecvente, se ol 
că există o similaritate evidentă. Considerăm din nou relația “Achiziţii” şi interogarea iceberg 
de la începutul acestei secţiuni. Se caută perechile (ldclient, Produs) care au SUM 
(A Cantitate) >5. Folosind o variantă a proprietăţii a priori, se poate spune cà trebuie luate în 
considerare doar acele valori pentru câmpul Idclient unde clientul a cumpărat cel puțin $ 
produse per total. Se pot astfel genera obiecte prin următoarele interogări: 


Select A.Idelient From Achiziţii A Group by A. Idclient Having sum (A. Cantitate)>5 


Similar; se pot restricționa valorile candidate pentru câmpul produs prin următoarea 
interogare: 


Select A Produs From Achiziţii A Group by A.Produs Having sum (A.Cantitate)>5 


Dacă se restricţionează interogarea iceberg originală asupra grupurilor (Idclient, 
Produs) pentru care valorile câmpurilor sunt ieșirile celor două interogári penele 
elimina a priori un număr mare de perechi (Idclient, Produs). Deci, o posibilă strategie de 
evaluare este de a calcula întâi valorile candidate pentru câmpurile Idclient si Produs, si de a 
folosi combinații ale acelor valori care trec de pasul a priori, cum a fost exprimat în cele dou 
înterogări anterioare. Deci, interogarea iceberg este supusă la aceeaşi strategie de evaluare 
bottom-up care este folosită pentru a găsi seturi de obiecte frecvente. În particular, putem 
folosi proprietatea a priori astfel: se ia în considerare un grup doar dacă componentele 
individuale ale grupului satisfac condiţia exprimată în clauza Having. Îmbunătăţirea 
performanțelor acestei strategii de evaluare alternativă faţă de modul traditional de realizare a 
interogărilor poate fi semnificativă în practică. i 

Deşi strategia de procesare bottom-up elimină a priori multe grupuri, numărul de 
perechi (Idclient, Produs) poate fi foarte mare în practică - chiar mai mare decât memoria 


& É 


principală. În acest sens, au fost dezvoltate strategii eficiente care folosesc eşantionarea si 
tehnici sofisticate de hashing. 


12.3. Explorarea pentru descoperirea de reguli 


Au fost propusi numeroşi algoritmi care urmăresc descoperirea diferitor forme de 
reguli care descriu în mod succint datele. 


12.3.1. Reguli de asociere 


Relaţia “Achiziţii” va fi folosită pentru a ilustra regulile de asociere. Prin examinarea 
setului de tranzacţii din “Achiziţii”, se pot identifica reguli de forma (stilou) => (cerneală) 

Această regulă trebuie citită astfel: “Dacă un stilou este achiziţionat într-o tranzacție, 
este probabil că şi cerneala va fi procurată în aceeași tranzacție. 

Este o declaraţie care descrie tranzacţiile existente în baza de date; extrapolarea la 
tranzacțiile viitoare trebuie făcută cu atenție. 

Mai general, o regulă de asociere are forma LHS=>RHS, unde şi LHS si RHS sunt 
seturi de obiecte. Interpretarea unei astfel de reguli este că, dacă într-o tranzacţie este 
achiziţionat fiecare obiect din LHS, atunci este probabil ca şi obiectele din RHS să fie 
achiziţionate. 

Există două măsuri importante pentru o regulă de asociere: 

- Suportul: Suportul unui set de obiecte este procentajul tranzacţiilor care contin 
toate aceste obiecte. Suportul pentru o regulă LHS => RHS este suportul pentru 
setul de obiecte LHS U RHS. De exemplu, se consideră regula 
(stilou)=>(cerneală). Suportul acestei reguli este suportul setului de obiecte 
Days cerneală), care este de 75% 

Încrederea: Se consideră tranzacţiile care conţin toate obiectele din LHS. 
Încrederea pentru o regulă LHS=>RHS este procentul din aceste tranzacții care 
conțin, de asemenea, toate obiectele din RHS. Fie sup(LHS) procentajul 
tranzacţiilor care contin LHS, şi fie sup(LHS U RHS) procentajul tranzacţiilor care 
conţin atât LHS, cát şi RHS. Astfel, încrederea in regula LHS=>RHS este 
sup(LHS)/sup(LHS U RHS). Încrederea unei reguli indică tăria acestei reguli. 
Procentul de încredere al regulii (stilou)=>(cemeală) este de 75%; 75% din 
tranzacţiile care conţin setul de obiecte (stilou) conţin de asemenea şi setul de 
obiecte (cemeală). 


12.32. Algoritm pentru găsirea regulilor de asociere 


Un utilizator poate solicita toate regulile de asociere care au un suport minim 
specificat (minsup) şi o încredere minimă (mincon), si au fost dezvoltați diferiţi algoritmi 
pentru găsirea eficientà a acestei reguli. Aceşti algoritmi se desfăşoară în doi paşi. În primul 
a ranger optat era ne nns Ce fii 

al doilea pas, sunt generate regulile folosind seturi de obiecte frecvente ca intrări. 

Odată ce sunt identificate seturile de obiecte frecvente, pasul următor este generarea 
tuturor regulilor posibile cu suportul minim specificat de utilizator. Se consideră un set de 
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obiecte frecvente X cu suportul Sx identificat în primul pas al algoritmului. Pentru a genera o 
regulă pentru X, vom împărți X în două seturi de obiecte LHS si RHS. Încrederea regulii 
LHS=>RHS este Sv/SLHS. Din proprietatea a priori se ştie că suportul lui LHS este maj 
mare decât minsup şi suportul lui LHS s-a calculat în primul pas al algoritmului. Se pot 
calcula valorile încrederii pentru regulile candidate prin calcularea raportului 
suport(X)/suport(L.HS) si apoi se verifică cu intervalul mincon. 

În general, pasul costisitor al algoritmului este calcularea seturilor de obiecte frecvente 
şi au fost dezvoltați mulți algoritmi pentru a realiza în mod eficient acest pas. 

Următorul pas este generarea regulilor, dat fiind faptul că au fost identificate toate 
seturile de obiecte frecvente. 


12.3.3. Regulile de asociere şi ierarhiile ISA 


În multe cazuri se impune o ierarhie ISA sau o ierarhie pe categorii asupra seturilor de 
obiecte. În prezența unei ierarhii, o tranzacţie conţine implicit, pentru fiecare din obiectele 
sale toți predecesorii obiectelor în ierarhie. De exemplu, se consideră ierarhia categoriilor 
prezentate în figura 12.6. Dată fiind această ierarhie, relaţia “Achiziţii” este conceptual sporită 
Cu cele opt înregistrări din figura de mai jos. Ca urmare, relaţia “Achiziţii” are toate tuplurile 
iniţiale plus tuplurile ilustrate în figura 12.7. 

lerarhia permite detectarea relaţiilor dintre obiecte la diferite nivele ale ierarhiei. De 
exemplu, suportul setului de obiecte fcerneală,suc) este de 5096, dar dacă se înlocuiește 
“sucul” cu o categorie mai generală numită “băuturi”, suportul setului de obiecte rezultat 
(cerneală, băuturi) creşte la 75%. În general, suportul unui set de Obiecte poate creşte doar 
dacă un obiect este înlocuit de unul din predecesorii săi în ierarhia ISA. 

Presupunând că adăugăm fizic la relaţia “Achiziţii” cele opt înregistrări arătate in 
figura 12.7, se poate folosi orice algoritm pentru calcularea seturilor de obiecte frecvente din 
baza de date mărita. Presupunând că ierarhia încape în memoria principală, se poate executa 
adăugarea în acelaşi timp cu scanarea bazei de date, ca o optimizare. 


Papetărie Băuturi 
Stilou Cemeala Suc Lapte 
Fig. 12.6 Taxonomia categoriilor ISA 
E ldtranz Idelient Data d Produs Cantitate 
n 201 5/1/99 Papetărie 3 
f ui 201 5/1/99 | Băuturi 9 
112 105 | 63/99 ^|  Papetărie 2 
112 105 | 6399 | Băuturi 1 
113 106 | se Papetárie | 1 
113 106 5/99 Băuturi 1 
| 114 201 5/15/99 Papet&rie 4 
114 201 5/15/99 Băuturi 4 


Fig. 12.7 Adăugări conceptuale la relaţia Achiziţii cu Ierarhia ISA 
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12.3.4. Reguli de asociere generalizate 


Desi regulile de asociere au fost studiate pe larg in contextul analizei coșului de 
cumpărături sau analizei tranzacţiilor clientului, conceptul este mai general. 

Considerăm relaţia ^A. i" ilustrată mai jos, grupată după identitatea clientului. 
Prin examinarea setului de grupuri de clienți, putem identifica reguli de asociere ca 
(stilou)=> (cerneală). Această regulă ar trebui citită astfel: “Dacă un stilou este cumpărat de 
un client, este posibil ca şi laptele să fie achiziționat de acel client. În relaţia “Achiziţii” de 
mai jos, această regulă are si suportul si încrederea de 100%. 


[. ldtranz Tdelient Data Cantitate 
105 6/3/99. 1 
105 6/3/09. 1 
105 6/3/99. 1 
106 5/1/99 1 
106 5/1/99 | 1 
201 5/15/09 Stilou 2 
201 5/15/99 |___ Cerneala 2 
m 114 201 5/15/99 Suc 4 
| 111 201 5/1/99 Stilou 2 
lu | 201 5/1/99 Cemeala 1 
1 201 5/1/99 lapte 3 
| 11 201 5/1/99. Suc. 6 


Fig. 12.8 Relaţia Achiziţii sortată după identitatea clientului. 


Similar, se pot grupa tuplurile după dată şi identifica reguli de asociere care descriu 
comportamentul de Achiziţii din aceeași zi. De exemplu, se consideră din nou relația 
Achiziţii, În acest caz, regula (stilou) => (ceneală) este acum interpretată astfel. Dacă într-o zi 
a fost cumpărat un stilou, este probabil că se va cumpăra si lapte, 

Dacă folosim câmpul Data ca atribut de grupare, pot fi luate în considerare probleme 
mai generale numite analiză calendaristică a coșului de cumpărături. În analiza coșului de 
cumpărături, utilizatorul specifică o colecție de calendare. Un calendar este orice grupare de 
date, de exemplu, fiecare Marţi a anului 2006 sau fiecare început de lună. O regulă se 
consideră respectată dacă este respectată pentru fiecare zi a calendarului. Fiind dat un 
calendar, se pot calcula reguli de asociere pe setul de date pentru care câmpul Data aparține 
calendarului considerat. Prin specificarea unor calendare, se pot identifica reguli care pot să 
nu aibă destul suport si încredere în raport cu întreaga bază de date, dar au destul suport si 
încredere pentru subsetul de tupluri al căror câmpuri de date ca în calendar. 

Pe de altă parte, chiar dacă o regulă ar putea avea destul suport si încredere în raport 
cu întreaga bază de date, ar putea câştiga suportul doar din tupluri care au căzut în calendar. În 
acest caz, suportul regulii pentru tuplurile din calendar este semnificativ mai mare decât 
suportul în raport cu întreaga bază de date. 

Fie relația Achiziţii cu calendarul „fiecare început al lunii”. Cu acest calendar, regula 
(stilou)=>(lapte) are suport si încredere 100% , unde pentru întreaga relație Achiziţii are 
suportul de doar 50%. 

Au fost propuse şi specificaţii mai generale ale condiţiilor care trebuie sa fie adevărate 
pentru un grup pentru a respecta o regulă (pentru acel grup). Putem spune că toate obiectele în 
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LHS za fost cumpärate într-o cantitate mai mică de două bucăţi si toate obiectele din RHS 
fost ackiziţiona:e într-o cantitate mai mare decât trei. 

Folosind diferite opțiuni pentru gruparea atributelor şi condiții sofisticate, se por 
idertfza reguli care sunt mai complexe care păstrează structura esenţială a unei reguli de 
asociere ca o condiţie asupra unui grup, cu suportul și încrederea definite ca de obicei. 


12.3.5. Modele secvențiale 


„Consideram relația “Achiziţii” din figura 12.4. Fiecare grup de tupluri având acecași 
clientului (ldclient), poate fi considerat ca o secvenţă de tranzacţii ordonate după 
da:ă. Aceasta ne permite să identificăm în timp modelele de cumpărare care apar frecvent. 
Fiecare tranzacţie este reprezentată de un set de tupluri si prin valorile din câmpul 
Produs se identică serul de obiecte achiziționate în acea tranzacţie. Deci, secvența 
zanzaztilor asociate unui client corespund unei secvențe de seturi de obiecte achiziţionate de 
De exemplu, secvența achiziţiilor pentru clientul 2 este (stilou, cerneală, lapte, suc), 
erneală, suc). 

O subsecvenjd a unei secvenţe de seturi de obiecte este obținută prin ştergerea unuia 
3e r£ multor seturi de obiecte şi este de asemenea o secvenţă de seturi de obiecte. O 
„am) este conținută într-o secvență S dacă S are o subsecvenţă (bl,...bm) cu 
i<m. Secvența {stilou}, (cerneală, lapte), (stilou, suc) este conținută în 
ernea!£:, (tricou). (suc, cerneală, lapte), (suc, lapte, cerneală). 
uportul peatru o secvență S a unui set de obiecte este procentul secvenjelor unui 
mru care S este o subsecvenţă. Problema identificării modelelor secvențiale constă în 
ate secvențele care au un suport minim specificat de utilizator. O secvenţă sI, 52, 
jn cu un suport minim arată că clienţii cumpără frecvent obiectele din setul s1 într-o 
:, apoi intr-o tranzacție succesivă cumpără obiectele din setul 2, apoi obiectele din 
intr-o tranzacţie ulterioară, S.a.m d. 
Ca si regulile de asociere, modelele secvențiale sunt afirmaţii referitoare la grupurile 
din baza de dare curentă. Din punct de vedere al procesării, algoritmii pentru 
z secvențiale frecvențele seamănă cu algoritmii pentru găsirea seturilor de 
Secvenze. Secvenjele lungi cu suportul minim necesar sunt identificate iterativ, într-o 
manieră care este foarte similar cu identificarea iterativţ a seturilor de obiecte frecvente. 


12.3.6. Folosirea regulilor de asociere pentru predicții 


Regulile de asociere sunt folosite la scară largă pentru previzionări, dar este important 
să zece zoaştem că astfel de previzionări nu sunt justificate fără o analiză ulterioară sau alte 
e din domeniu. Regulile de asociere descriu exact datele existente, dar pot fi confuze 
six sa folosite naiv pentru precicție. De exempl, fie regulă (stilou) > (cerneala). 3 

Încrederea asociată acestei reguli este probabilitatea condiționată de a achiziţiona 
cezzezia dată fiind achiziționarea unui stilou, în baza de date curentă. Aceasta este o măsură 
cescriptivă. Putem folosi această regulă pentru vânzarile promoţionale viitoare. De exemplu, 
Hee A orez di pina cop te Ma ct ici tit E 
şi ia ceczealá. 

Giza — —— 
zi v&zziilor de cerneala în tranzacţiile viitoare. Aceasta presupunere este justificata 
PA PE ne da mai bena me Pee a eee jeni RN 
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dacă cumpărarea de stilouri face ca clientul să cumpere şi cerneală. Oricum, se pot aplica 
reguli de asociere cu supoit şi încredere înalte în situaţii unde nu există nici o legătură cauzală 
între LHS şi RHS. De exemplu, se presupune că stilourile sunt achiziționate întotdeauna 
împreuna cu creioanele, probabil din cauza tendinței clienţilor de a comanda instrumente de 
scris împreună. Se poate introduce regula: 

fereion] -» (cernealá) cu acelaşi suport si încredere ca şi regula: 

stilou] =>. (cerneală). 

Oricum, nu există nici o legătura cauzală între creioane şi cerneală. Dacă promovăm 
creioanele, un client care achiziţionează mai multe creioane din cauza promoliilor nu are nici 
un motiv pentru a cumpăra mai multă cerneală, Deci, o promoţie care face discount la 
creioane pentru a creşte vânzările la cerneală ar fi inutilă. 

În practică, ar fi de aşteptat ca prin examinarea unei baze de date mari ale tranzacţiilor 
istorice (colectate într-o perioadă mai mare de timp şi o varietate de circumstanțe) şi 
restrângând atenţia către reguli care apar des (care au suport mare) sa fie minimizate regulile 
care ghidează greşit. Oricum, trebuie reţinut faptul că vor fi generate şi reguli greşite, 
necauzale. Deci, va trebui să tratăm regulile ca posibile, nu concluzive, identificând relaţiile 
cauzale. Deşi regulile de asociere nu indică relaţii cauzale între LHS şi RHS, elc oferă un 

de pornire pentru identificarea relaţiilor de acest fel, fie analizând în continuare, fie 
apelând un expert în domeniu; acesta este motivul pentru popularitatea lor, 


12.3.7. Relaţiile Bayesian 


Găsirea relaţiilor cauzale este o sarcină solicitantk În general, dacă anumite 
evenimente sunt intens corelate, există multe explicaţii posibile. 

De exemplu, presupunem că stilourile, creioanele şi cerneală sunt cumpărate frecvent 
împreună. Poate fi pentru că achiziționarea unuia dintre produse (de exemplu, cerneala) 
depinde cauzal de achiziţionarea unui alt produs (de exemplu, stilou), este puternic corelata cu 
achiziţionarea altuia (de exemplu, creion) sau poate fi din cauza ca achiziţionarea unuia 
dintre produse este puternic corelată cu cumpărarea altuia din cauza existenţei unui fenomen 
(de exemplu, tendinţa de a te gândi la mai multe instrumente de scris împreuna) care 
influenţează cauzal ambele achiziţii. Cum putem identifica relaţiile cauzale adevărate 
existente evenimente în lumea reală? 

O posibilă abordare pentru a identifica relaţiile cauzale reale existente — intre 
evenimente este de a considera fiecare combinaţie posibilă a relaţiilor cauzale dintre 
variabilele sau evenimentele de interes şi de a evalua probabilitatea fiecărei combinaţii pe 
baza setului de date disponibile. Dacă privim fiecare combinaţie de relaţii cauzale ca pe un 
model al lumii reale pe baza datelor colectate, se poate atribui un scor fiecărui model, în 
funcţie de cát de concordant este cu datele observate. Rețelele bayesiene sunt grafuri care pot 
fi folosite pentru a descrie o categorie de astfel de modele, care prezintă câte un nod pentru 
fiecare variabilă sau eveniment şi un arc între noduri pentru a arăta cauzalitatea. Figura 12.9 
jos reprezintă un model posibil al exemplului cu creioane, stilouri şi cerneală. 
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Fig. 12.9. Reţea bayesiană pentru indicarea cauzalitàfii 


12.3.8. Reguli de clasificare şi regresie 


Fie următorul view care conţine informaţii referitoare la o campanie efectuată de o 
companie de asigurări: 


Infoasig( vârsta:integer; model. maşină: string; rise_major :boolean) 


View-ul confine informaţii despre clienții actuali. Fiecare înregistrare conţine vârsta şi 
modelul de maşina al clientului, precum şi un indicator care arată dacă persoana este 
considerată un client cu rise major. Dacă indicatorul este adevărat, clientul este considerat 
client cu risc major. Aceste informații vor fi folosite pentru a identifica reguli care să prezică 
riscul de asigurare al noilor solicitanţi de asigurări a căror vărsta şi model de magina sunt 
cunoscute. De exemplu, o astfel de regula ar pute fi: “Dacă vârsta este între 16 şi 25, iar 
modelul de maşină este sport ori autocamion, atunci riscul este major." 

Atributul desemnat pentru realizarea previzionării se numeşte atribut dependent 
Celelalte atribute sunt numite arribute predictor. În exemplul considerat, atributul dependent 
în analiza informaţiilor despre asigurare este riscul de asigurare, iaz atributele predictor sunt 
vârsta si modelul maşinii. Forma generală a tipurilor de reguli căutate este: 


PiXU^P4X))... ^P.) => Yoc. 


Atributele predictor X;,....... Xy sunt folosite pentru a prezice valoarea atributului 
dependent Y. Ambele părți ale unei reguli pot fi interpretate drept condiţii asupra câmpurilor 
unui tuplu. P(X;) sunt predicate care implică atributul X, Forma predicatului depinde de tipul 
atributului predictor. Distingem două tipuri de atribute: mumerice şi categorice. Pentru 
atributele numerice, putem efectua calcule precum calcularea mediei a două valori, pe când 
pentru atributele categorice, domeniul lor este un set de valori. În analiza informaţiilor despre 
asigurări, vârsta este un atribut numeric pe când modelul mașinii şi riscul sunt atribute 
categorice. Revenind la forma predicatelor, dacă X; este un atribut numeric, predicatul sau Pi 
este de forma I;SX;Sh;; dacă X; este un atribut categoric, P; este de forma X; e (vi.....v;). E 

Dacă atributul dependent este categoric, regulile se numesc reguli de clasificare. Dacă 
atributul dependent este numeric, regulile se numesc reguli de regresie. * 

De exemplu, fie din nou regula din exemplul precedent: " Dacă vârsta este cuprinsă 
între 16 şi 25 jas modelul iati este ori sport ari autocamion, atone? isetă este mejor". Pu 


vreme ce riscul este un atribut categoric, această regulă este de clasificare. Putem exprima 


această regulă formal după cum urmează: 


L 
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(16<vârstas25)"(modelul maşinii € (Sport, autocamion))=> (risc-major=adevărat) 


Putem defini suportul şi încrederea pentru regulile de clasificare şi regresie, ca şi 
pentru regulile de asociere: 

- suportul: suportul pentru o condiție C este procentul tuplurilor care satisfac 

condiţia C. Suportul pentru regula C1=>C2 este suportul pentru condiţia C1^C2. 

- încrederea: fie acele tupluri care satisfac condiţia C1. Încrederea pentru o regulă 

C1=>C2 este procentul din acele tupluri care satisfac condiţia C2. 

Pentru o mai amplă generalizare, fie partea dreaptă a unei reguli de clasificare sau 
regresie: Y=c, Fiecare regulă prezice o valoare a lui Y pentru un tuplu dat pe baza valorilor 
atributelor predictor X. X. 

Regulile de clasificare şi regresie diferă de regulile de asociere prin analizarea 
câmpurilor continue şi tip categorie, şi nu a unui singur câmp care este set de valori. 

Regulile de clasificare şi regresie au multiple aplicaţii. Exemplele pot include 
clasificarea rezultatelor unor experimente ştiinţifice, unde tipul obiectului de recunoscut 
depinde de măsurătorile făcute, prospectarea pieţei prin poştă, unde răspunsul unui client la o 
promoţie este o funcţie de nivelul de trai şi vârsta sa. Exemple de aplicaţii ale regulilor de 
regresie includ preziceri financiare, unde preţul cafelei ar putea fi în funcţie de ploile din 
Columbia în urmă cu o luna. 


12.4. Reguli structurate sub forma de arbori 


În cele ce urmează se va discuta descoperirea regulilor de clasificare şi regresie dintr-o 
relaţie, dar vor fi luate în considerare numai regulile care au o structură specială, care pot fi 
reprezentate printr-un arbore, iar în mod tipic arborele însăşi este rezultatul activităţii de 
căutare a datelor. Arborii care reprezintă reguli de clasificare se numesc arbori de clasificare, 
iar arborii care prezintă reguli de regresie se numesc arbori de regresie. 


Fig. 12.10 Arbore de decizie pentru exemplul Riscul de asigurare 


În arborele din figura de mai sus, fiecare cale de la rădăcină spre o frunză reprezintă o 
regulă de clasificare. De exemplu, calea de la rădăcină până la frunza cea mai din stânga 
reprezintă regula de clasificare: "Dacă o persoană are 25 de ani sau mai puţin și conduce o 
Dacie, atunci este probabil să aibă un risc de asigurare scăzut”. Calea de la rădăcină spre 
frunza cea mai din dreapta reprezintă regula de clasificare: “Dacă o persoană are mai mult de 
25 de ani atunci este probabil să aibă un risc de asigurare scăzut”. 


Regulile structurate sub forma de arbori sunt foarte populare deoarece sunt uşor de 
interpretat. Ugurinfa înțelegerii este foarte importantă, deoarece rezultatul oricătei activități de 
căutare a datelor trebuie sa fie pe înţelesul celor nespecialişti. În plus, studiile au arătat că 
indiferent de limitările de structură, regulile structurate în arbori sunt foarte exacte. Există 
algoritmi eficienţi pentru a construi reguli structurate ca arbori din date de baze de mari 
dimensiuni. 


12.4.1. Arbori de decizie 


Un arbore de decizie este reprezentarea grafică a unei colecţii de reguli de clasificare, 
Având o înregistrare, arborele conduce înregistrarea de la rădăcină spre o frunză. Fiecare nod 
intern al arborelui este etichetat cu un atribut predictor. Acest atribut este adesea numit atribur 
de scindare, deoarece datele sunt scindate în funcție de condiţiile pentru acest atribut. Ieşirile 
unui nod intern sunt etichetate cu predicate care implică atributul de scindare al nodului; 
fiecare înregistrare care intră în nod trebuie să satisfacă predicatul, etichetând astfel o singură 
ieşire. Informaţia combinată despre atributul de scindare şi predicatele de pe ieşiri este numit 
criteriul de scindare al nodului. Un nod fără ieşiri este numit nod frunza. Fiecare nod frunză 
al arborelui este etichetat cu o valoare a atributului dependent. Vor fi luaţi în considerare 
numai arbori binari, în care nodurile interne au două ieşiri, cu toate că sunt posibili si arbori 
cu grade superioare, 

În arboreie de decizie din figura de mai sus, atributul de scindare al nodului rădăcină 
este vârsta, atributul de scindare al copilului din stânga al rădăcinii este modelul maşinii 
Predicatul de pe ieşirea din stânga ai nodului rădăcina este vârsta mai mică sau egală cu 25, 
predicatul de pe marginea exterioară dreaptă este vârsta mai mare decât 25. 

Fiecărui nod frunza din arbore i se poate asocia acum o regulă de clasificare, după 
cum urmează. Se ia în considerare calea de la rădăcina arborelui până la nodul frunză. Fiecare 
legătură de ieşire a acestei căi este etichetată cu un predicat. Legătura dintre toate aceste 
predicate formează partea stângă a regulii. Valoarea atributelor dependente în nodul frunză 
formează partea dreaptă a regulii. Așadar, arborele de decizie reprezintă o colecţie de reguli 
de clasificare, câte una pentru fiecare nod frunză. 

Un arbore de decizic este construit de obicei în două faze. În prima fază, faza de 
creştere este construit un arbore foarte mare. Acest arbore reprezintă înregistrările în baza de 
date interne foarte clar, de exemplu, un arbore ar putea să conţină noduri frunză pentru fiecare 
înregistrare din baza de date interni. În faza a doua, fază de curățare, este determinată 
dimensiunea finală a arborelui. Regulile reprezentate în arbore în prima fază sunt de obicei 
supraspecializate. Reducând dimensiunea arborelui, se generează un număr mai mic de reguli 
mai generale, care sunt mai bune decât un număr mare de reguli foarte specializate. 

Algoritmii pentru arbori de clasificare construiesc arborele gradat, top-down, în felul 
următor. În nodul rădăcină este examinată baza de date şi este calculat cel mai bun criteriu 
“local” de scindare. Baza de date este astfel partiţionată, în funcţie de criteriul de scindare 2 
nodului rădăcină, in două părți, o partiție pentru copilul din stânga şi una pentru cel din 
emita. Algoritmul se repetă pentru fiecare copil. Această schemă este prezentată în figu 
1241. 

Criteriul de scindare pentru un nod este găsit prin aplicarea unei metode de selecție de 
scindare. O metodă de selecţie de scindare este un algoritm care primeşte ca intrare o relaţie $ 
are ca rezultat cel mai bun criteriu “local” de scindare. În exemplul nostru, metoda analizeszi 
atributele Tip_maşină si Vârsta, selectează unul dintre cle drept atribut de scindare, iar 2p? 
selectează predicatele de scindare. 


Contruire arbore(nod n, partitie date D, merodă_ scindare S) 
Se aplică S pentru D pentru a găsi criteriul de scindare 
if (e găsit un criteriu de scindare bun) 

Creează două noduri copil pentru n, nl si n 
Partifioneazà D în Di şi D2 
Contruire arbore(nl,D1,S) 
Contruire arbore(n2,D2,) 
endif 


Fig. 12.11. Schema de dezvoltare top-down a arborelui de decizie 


aim 


Md 


12.42. Un algoritm de construire a arborilor de decizie 


Dacă baza de date se încadrează in memoria principală, se poate urmări direct schema 
inducţie pentru arborele de clasificare din figura 12,10. Cum se pot construi arbori de 
decizie când relaţia intrărilor este mai mare decât memoria principală? În acest caz, primul 
pes din figură este greşit, deoarece baza de date de intrare nu se încadrează în memoria 
principală. Dar se poate face o observaţie importantă despre metodele de selecție de scindare 
* care ajuta la reducerea acelei cererii de memorie principale. 

E Se consideră un nod al arborelui de decizie. Metoda de selecţie de scindare trebuie să 
ia două decizii după examinarea partiției la acel nod (i). Trebuie să selecteze atributul de 
scindare, si (ii) trebuie să selecteze predicatele de scindare pentru ieşirile sale. O dată ales 
criteriul de scindare, algoritmul este aplicat recursiv fiecărui copil al nodului, Are nevoie o 
metodă de selecţie de scindare de întreaga partiție a bazei de date ca intrare? Din fericire, 
răspunsul este negativ. E 
Metodele de selecție de scindare care calculează criterii de scindare ce implică un 
singur atribut predictor pentru fiecare nod, evaluează individual fiecare atribut predictor. Din 
moment ce este examinat separat fiecare atribut, metodei de selecție de scindare i se pot 
fumiza informaţii agregate despre baza de date, în loc să se încarce întreaga bază de date in 
memoria principală. Dacă sunt selectate corect, aceste informaţii de agregare sunt suficiente 
pentru a calcula cel mai bun atribut de scindare. 


——— 


Lj Vârsta | Tip magina | Risc major 
jene Dacie False | 
[32 | Sport False | 
33 Dacie False 
$ 24 Autocamion | True 
> 34 Dacie False 
: 21 Autcamion | — True 
36 Autocamion | False 
25 | Spot True 
19 | Dacie false 


Fig. 12.12 Relatía Asigurare 


Din moment ce metoda de selecţie de scindare examinează toate atributele predictor, 
este nevoie de informaţii agregate despre fiecare atribut predictor în parte. Această informaţie 
îgregată este denumita serul AVC al atributului predictor. Acronimul AVC vine de la Atribut- 
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Valoare, etichete de Clase, deoarece valorile atributului dependent sunt de obicei umite 
etichete de clase. Setul AVC al atributului predictor X în nodul n este proiecția partiției bazei 
de date a lui n pe X si pe atributul dependent pentru care sunt agregate valorile individuale ale 
domeniului atributului dependent. De exemplu, fie relația InfoAsigurare din figura de mai Sus, 
Setul AVC al nodului rădăcină al arborelui pentru atributul predictor vârsta este rezultatu] 
următoarei interogări: 


SELECT 1 Vârsta, LRisc_major, COUNT(*) FROM InfoAsigurare I 
GROUP BY 1 Vârstă, LRisc_major 


Setul AVC pentru copilul din stânga al nodului rădăcină pentru atributul predictor 
modelul maşinii este rezultatul următoarei interogări: 


SELECT Tip_maşină, LRisc. major, COUNT(*) FROM Info4sigurare I 
WHERE LVársta <=25 GROUP BY LVársta, I.Risc, major 


Cele două seturi AVC ale nodului rădăcină sunt prezentate in figura 12.13. 


Tip magina | Risc major | Risc major 
= true = false. 
Dacie Ca ua me 
= Sport 1 ~ 
Autocamion 2 T 
j 
Vârsta | Rise_major = true | Rise_major = true 
18 0 1 
23 1 1 ] 
[ 25 2 0 
[30 [] 3 
[.36 0 1 


Fig, 12.13 Seturi AVC ale nodului rădăcina 


Considerăm un grup AVC al nodului n ca fiind setul seturilor AVC ale tuturor 
atributelor predictor pentru nodul n. În exemplul cu informaţii despre asigurare, există două 
tipuri de atribute, de aceea grupul AVC al fiecărui nod va conţine două seturi AVC. P 

Cât de mari sunt seturile AVC? Este bine de ştiut ca mărimea unui set AVC a unui 
atribut X al unui nod n depinde doar de numărul de valori ale atributului X şi de mărimea 
domeniului atributului dependent. am 

De exemplu, fie setul AVC reprezentat în figura 12.13. Setul AVC pentru atributul 
predictor “tipul maşinii” are trei intrări, iar setul AVC pentru atributul predictor “Vârsta” att 
cinci intrări, desi informaţiile despre asigurare prezentate în figura 12.12 au nouă înregistrări... 


Pentru baze de date mai mari, mărimea setului AVC este independentă de numărul de _ 


tupluri din baza de date, excepţie făcându-se doar în cazul în care există atribute cu 
mari. 

^ Dacă se presupune că toate seturile AVC ale nodului rădăcină ar încăpea exact 
memoria principală, s-ar putea construi arborele de decizie dintr-o bază de date de 
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dimensiuni, după cum urmează: se parcurge baza de date si se construiește în memorie grupul 
AVC al nodului rădăcina. Apoi se executa metoda aleasa de scindare a secţiunii, cu setul 
AVC construit ca intrare. După ce metodă aleasă calculează cel mai bun atribut de scindare şi 
predicatele de scindare pentru nodurile de ieșire, se partifioneazà baza de date, şi se aplică din 
nou, recursiv, algoritmul. 


12.5. Clusterizarea (gruparea) 


În această secțiune este prezentată problema clusterizării. Scopul este de a partifiona 
un set de înregistrări în grupuri, în aa fel încât înregistrările dintr-un grup să semene între ele, 
în timp ce înregistrările care aparțin de două grupuri diferite nu sunt similare. Fiecare grup se 
numeşte; cluster, şi fiecare înregistrare aparține exact unui cluster. Similitudinea între 
înregistrări poate fi măsurată printr-o funcție distanţă. O funcție distanță ia ca parametrii de 
intrare două înregistrări si returnează o valoare care exprimă similaritatea dintre ele. 
Aplicațiile pot avea noțiuni diferite despre similaritate, astfel încât nu există o măsura unică 
pentru toate domeniile. 


ConstruireArbore(nod n, partiţie_date D, metoda_scindare S) 
Se parcurge D si se construieşte grupul AVC de n în memorie 
Se aplica S grupului AVC pentru a găsi criteriul de scindare 


Fig. 12.14 Clasificarea arborilor de inducție rafinată cu grupuri AVC 
Ca exemplu se poate considera schema InfoClienţi: 
Clienţi(vârsta:interger, salarii:real) 


Înregistrările pot fi reprezentate în spaţiul bidimensional. Cele două coordonate ale 
unei înregistrări sunt valori ale înregistrării pentru câmpurile vârstă si salariu. Se pot astfel 
identifica trei clustere: clienti tineri care au salarii mici, clienţi tineri care au salarii mari si 
clienți mai în vârstă care au salarii mari. De obicei, ieşirile unui algoritm de clusterizare sunt 
formate din reprezentările sumarizate ale fiecărui cluster. Tipul reprezentării sumarizate 
depinde foarte mult de tipul si forma clusterelor obținute de algoritm. 

Spre exemplu, pot fi grupuri sferice, ca în figura 12.15, si se poate rezuma fiecare grup 
prin propriul lui centru $i raza, după cum urmează. 

Fie o colecţie de înregistrări ri,...., Ta, cu centrul C si raza R definite ca: 

n 26-M) 

C-Yn şi Rejim 

r^i n 


Există două tipuri de algoritmi de clusterizare. Un algoritm de clusterizare partifional, 
Care imparte datele in k grupuri astfel încât criteriului de evaluare a calităţii clusterizării sa fie 
optimă. Numărul de clustere k este un parametru a cărui valoare este specificată de utilizator. 
Un algoritm de clusterizare ierarhic generează o secvență de partijii ale înregistrărilor. Se 
Începe cu o partiție în care fiecare cluster e format dintr-o singură înregistrare, apoi algoritmul 
fuzionează câte două partiţii la fiecare pas, până când la sfârşit rămâne o singură partiție. 


12.5.1. Algoritm de clusterizare 


Clusterizarea este o problemă foarte veche şi au fost deja dezvoltați mulţi algoritmi în 
acest sens. Tradițional, numărul de înregistrări din baza de date de intrare s-a presupus a fi 
relativ mic, iar completarea ulterioară a bazei de date s-a presupus a încăpea în memoria 
internă. În continuare va fi descris un algoritm de clusterizare numit BIRCH pentru baze de 
date mai mari. 

Algoritmul reflectă următoarele două presupuneri: 

- numărul de înregistrări este foarte mare si de aceea se doreşte o singură scanare a 


bazei de date; 
- memoria disponibilă este limitată. 
Salariul c 
eo 
B e. 
60k 
30k A. e 
e 
e o 
e 


20 40 Cora as 


Fig. 12.15. Înregistrările din InfoClient 


Un utilizator poate seta doi parametri de control ai algoritmului BIRCH. Primul 
parametru este un prag al cantității de memorie principală disponibilă. Acest prag al memoriei 
principale se transformă într-un numâr maxim de sumarizări de grupuri care pot fi păstrate 
în memoria internă. Al doilea parametru “e” este un prag iniţial pentru raza oricărui grup. 
Valoarea pentru “e” este limită superioară a razei oricărui grup şi controlează numărul de 
grupuri găsite în cadrul algoritmului. 

„Dacă “e” e mai mic, sunt găsite mai multe clustere mici. Dacă “e” este mai mare, sunt 
găsite clustere puţine de o mărime relativ mare, Un cluster este ca un grup este compact dacă 
raza sa e mai mică decât “e”. 

Algoritmul păstrează k sau câteva sumarizări de clustere (C; R;) în memoria principală, 
unde C; e centrul clusterului, iar R raza clusterului. Algoritmul păstrează întotdeauna clustere 
compacte, pentru care raza fiecărui cluster e mai mică decât e. Dacă această invariantă nu 
poate fi memorată dată fiind memoria principală disponibilă valoarea dată, "e" va creşte după 
cum se descrie mai jos. 

Algoritmul citeşte secvențial înregistrările din baza de date şi le procesează astfel: 

- calculează distantele dintre înregistrarea “r” si centrul fiecărui cluster. Fie "f" un index 

pentru clusterul respectiv, astfel încât distanța între r si Ci are cea mai mică valoare. 

- calculează valoarea pentru noul R; pentru al i-lea cluster, presupunând ca acesta este 

grupul în care a fost inserată înregistrarea r. Daca R; <e, atunci cel de-al i-lea cluster 


362 


rămâne compact, şi “r” se asociază celui de-al i-lea grup, reactualizând centrul si 
setând raza R;. Dacă R;>e atunci al i-lea cluster nu va mai fi compact dacă va fi 
înserat ^r". Din acest motiv, se introduce un nou cluster care va confine doar 
i e să 

Cel de-al doilea pas prezintă probleme dacă avem deja un număr maxim de sumarizări 
de grupuri, "k”. Dacă se citeşte o înregistrare care necesită crearea unui nou grup, nu va fi 
memorie suficientă pentru a memora acest grup. în acest caz, se va mări valoarea pentru 
pragul “e”, folosind o metoda euristică pentru a fuziona cu posibilele grupuri existente. O 
creştere a lui “e” are două consecințe. Prima, clusterele existente vor avea mai multe 
7 înregistrări, din moment ce raza maximă a crescut. A doua, este posibil să fuzioneze grupuri 
T existente, astfel încât grupul rezultat să fie compact. Astfel, o creştere a lui “e” conduce, de 
L obicei, la o reducere a numărului de grupuri existente, 


À 


— 


^ 


. 12.6. Cercetarea similitudinii în cadrul secvenfelor 

£ O mare parte din datele memorate în baze de date sunt formate din secvențe. Se 
presupune, de exemplu, că un utilizator specifică o secvență interogare şi vrea să consulte 
toate secvențele de date care sunt similare cu secvența interogare. Căutarea de similitudini e 
diferită de interogările normale, de aceea nu prezintă interes numai secvențele care se 
potrivesc exact cu secvenţa interogare, dar şi de secvențele care se potrivesc parțial cu 


3). Uneori, X este numită și 
ie k lungimea secvenței. O subsecvenfá -zx) este obținută din altă 
...X4) ştergând numere de la începutul si sfârșitul secvenjei X. Formal, Z 
este o subăcevenţă a lui x, dacă zi-xi; 7X1... Xj=Zij} unde i€ (1,...„k-j+1). Fie date două 
secvenţe X={x1....xx} şi Y={y1..-Yx} se poate defini norma euclidiana ca distanţa dintre cele 
două secvenţe după cum urmează: 

IKEY Xy 


Dată fiind o secvenţă interogare a unui utilizator şi parametrul prag e, ținta este 
obținerea tuturor secvenţelor de date care se încadrează în distanta “e” faţă de secvenţa 
interogare. 

Interogările referitoare la similitudini în cadrul secvenfelor pot fi clasificate în doua 


- corespondența completă a secvenjelor. Secvența interogare şi secvențele din baza de 
date au aceeași lungime. Dat fiind pragul e specificat de utilizator, scopul este să se 
găsească toate secvențele din baza de date care se găsesc în cadrul distantei e față de 
secvenţa interogare. 

- corespondența subsecvenfelor. Secvența interogare este mai scurtă decât secvențele 
din baza de date. În acest caz se doreşte să se găsească toate subsecvenjele din baza de 
date care se află în cadrul distanţei e faga de secvenţa interogare. 


: 12.6.1. Un algoritm pentru găsirea secvenfelor similare 


A Dată fiind o colecţie de secvențe de date, o secvență interogare şi pragul pentru 
distanţa e, se doreşte găsirea celui mai eficient mod de a găsi toate secvențele care se află în 
cadrul distanţei e faţă de secvența interogare. 
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Capitolul 12 


O posibilitate ar putea fi parcurgerea bazei de date, consultarea fiecărei secvențe de 
date, şi calcularea distanței până la secvenţa interogare. Desi acest algoritm este foarte simplu, 
el consultă fiecare secvenţă de date. 

Deoarece se are în vedere cazul în care secvențele se potrivesc complet, toate 
secvențele de date si secvenjele interogare au aceeaşi lungime. Căutarea similitudinilor poate 
fi privită ca o problemă de indexare de mari dimensiuni. Fiecare secvență de date şi secvența 
interogare pot fi reprezentate ca nişte puncte într-un spaţiu k-dimensional. Astfel, dacă 
inseram toate secvențele de date într-un index multidimensional, putem găsi secvențele de 
date care se potrivesc exact cu secvența interogare interogând indexul. Dar din moment ce se 
urmăreşte a se găsi nu numai secvențele care se potrivesc exact secvenjei interogare, ci și cele 
care se află pe distanța "e" faţă de secvența problemă, nu se va folosi o interogare punct, cum 
a fost definită în secvenţa interogare. În loc de aceasta, se va interoga indexul cu un hiper. 
dreptunghi care are lungimea 2e si secvenţa interogare ca centru, şi vor fi astfel obținute toate 
secvențele care se găsesc în interiorul acestui hiperdreptunghi. Apoi se vor înlătura 
secvențele care sunt la distanță mai mare de “e” faţă de secvenţa interogare. 

Folosirea indexul permite o reducere foarte mare a numărului de secvențe luate în 
considerare, si astfel scade timpul de evaluare a similitudinilor. 


12.7. Perspectivele data mining 


Data mining a fost dezvoltată recent ca rezultat al cerințelor diverselor aplicaţii Este 
interdisciplinar, foloseşte arii tematice mari: baze de date, inteligenţa artificială şi statistica. 
Este o disciplină modernă, aflată încă în stadiile iniţiale ale dezvoltării, dar într-o evoluție 
foarte rapidă. Observând dezvoltarea actuală a disciplinei, apar unele probleme. În primul 
rând apare necesară si urgentă sistematizarea acesteia, pentru a permite diferitelor probleme 
de data mining sa fic vizualizate împreună. Până acum acestea au fost considerate separate de 
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către specialişti şi gestionate folosind sisteme specifice pentru fiecare problemă specifică. în 
viitorul apropiat este de aşteptat definirea unor modele standard pentru formularea 
problemelor de data mining și tehnici generale pentru rezolvarea lor. 
Este astfel necesară gestionarea unor seturi mari de date. Algoritmii actuali de data mining nu 
20! seu DE d RUNS MA jo Dix url bea da ete Bere mari Poobieaza posta f 
ici i care constau în data mini; 1 dar 
rezolvată kaian MN de dicticnm mining pe eşantioane reduse, 
În final, este necesară cunoaşterea nivelului până la care instrumentele de data mining 
pot fi independente. În multe cazuri, problemele pot fi rezolvate doar dacă se iau în 
considerare caracteristicile specifice problemei când se propune soluția. În afară de 
instrumentele generale de rezolvare, există de asemenea un mare număr de date specifice 
fiecărei probleme. Acestea au avantajul incontestabil de a cunoaşte domeniul aplicaţiei și pot 
astfel completa procesul de data mining mai ușor, în special în privința interpretării 
rezultatelor; dar sunt mai puţin generice si refolosibile. T 
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Baze de date multidimensional. 


Capitolul 13 
Baze de date multidimensionale 


Termenul de OLAP a fost folosit prima dată în septembrie 1993 de către Codd, în 
anicolul "Providing OLAP (On-line Analytical Processing) to User-Amalysis: An IT 
Mandate”. După ce a văzut SGBD-ul multidimensional Essbase (Arbor Software) a ajuns la 
concluzia că limbajul SQL nu a fost niciodată adecvat pentru analiza multidimensională a 
datelor. El a afirmat că există o diferență semnificativă între bazele de date relaționale si 
bazele de date multidimensionale . 

În 1995, consiliul OLAP definea conceptul de OLAP ca "o categorie de instrumente 
software, care permit analiştilor, managerilor şi directorilor să înţeleagă esența datelor 
printr-un acces rapid, consistent şi interactiv la o mare varietate de viziuni posibile ale 
informaţiilor, care au fost obținute prin tranformarea datelor primare astfel încât să reflecte 
dimensiunile reale ale întreprinderii aga cum o percepe şi o înţelege utilizatorul”. 

Aşa cum indică cuvintele folosite pentru a construi acronimul (*on-line", "analytic", 
“processing”), rolul sistemelelor OLAP într-o organizaţie este de a oferi un acces interactiv şi 
uşor la resursele analitice necesare procesului decizional şi de conducere. În teoria sistemelor 
suport de decizie sunt recunoscute două tipuri de resurse analitice: datele si modelele. 

Instrumentele OLAP sunt utilizate frecvent în sistemele suport de decizie, deoarece 
permit analiza interactivă a datelor multidimensionale. Avantajul lor principal este că sunt 
apropiate de modul de gândire al analiştilor si îmbunătățesc performanţa execuţiei cererilor. În 
consecinţă, tehnologia bazelor de date multidimensionale a câștigat, în ultima perioadă, multă 
atenţie din partea firmelor producătoare şi a cercetătorilor. Indiferent de tipul de arhitectură 
implementat, instrumentele OLAP prezintă datele la utilizator într-un model de date 
multidimensional, iar cererile OLAP sunt formulate utilizând paradigma multidimensională. 

In acest capitol vom prezenta: 

- conceptele de bază utilizate în modelarea multidimensională a datelor, 

- stadiul actual în stabilirea unui model multidimensional conceptual si formal 

standard; 

-~ facilităţile analitice oferite de limbajul SQL ; 

- avantajele unui mediu integrat relational-multidimensional, precum si arhitectura 

sistemelor OLAP. 


13.1. Concepte de bază 


Modelarea  multidimensională este fundamentală pentru bazele de date 
multidimensionale, depozitele de date şi aplicaţiile OLAP, iar modelul de date 
multidimensional este apropiat de modul de gândire al analistilor. 

Pentru a descrie în detaliu modelele de date multidimensionale şi a putea fi înţelese, 
tile necesar a se prezenta o serie de concepte de bază utilizate şi anume: 


EZ 


hypercubul (cub n-dimensional) 
dimensiunile 

ierarhiile 

măsurile 

fenomenul de imprăştiere 
multicubul 


„Aceste concepte apar în majoritatea modelelor multidimensionale propuse, deşi modul 
lor de definire diferă uneori foarte mult. De asemenea, consiliul OLAP a propus un glosar de 
termeni care se doreşte standardizat. De aceea, în prezentarea acestor concepte de bază s-au 
utilizat si definițiile date de Consiliul OLAP. 


13. 


Conceptul de cub n-dimensional 


Conceptul de hypercub sau cub cu mai mult de trei dimensiuni (cub n-dimensional) 
sau structură multidimensională este fundamental pentru înțelegerea sistemelor OLAP, a 
bazelor de date multidimensionale şi a modelului multidimensional. Instrumentele OLAP 
folosesc conceptul de Aypercub în acelaşi mod în care foile de calcul tabelar folosesc 
conceptul de foaie de lucru (worksheet) şi bazele de date relationale conceptul de rabelă 
Toate vizualizările, rapoartele şi analizele sunt făcute în termeni de hypercuburi (cuburi n- 
dimensionale). 

Consiliul OLAP defineşte hypercubul ca „un grup de celule de date aranjate după 
dimensiunile datelor. Dimensiunile tipice ale datelor dintr-o întreprindere sunt «timpu 
produsele, regiunile geografice, canalele de distribuţie, et 


Un cub n-dimensional este de fapt un set de măsuri (variabile/indicatori) ce utilizează 


aceleași dimensiuni de identificare. În figura 13.1 se prezintă un exemplu simplificat de 
hypercub utilizat în analiza vânzărilor. Acest Jypercub are trei dimensiuni: Locaţie, Produs si 
Timp. În celulele cubului sunt stocate valorile măsurii analizate si anume cantitatea vândură 
Valoarea acestui indicator variază în funcție de produsul vândut, de magazinul care vinde 
acest produs şi de perioada de timp. Se spune că acest indicator este „dimensionat” dup 
Produs, Locaţie si Timp. De exemplu, valoarea 57 reprezintă cantitatea vândută în 2003 din 
produsul X în magazinul A. 


Fig. 13.1. Exemplu de hypercub (cub n-dimensional) 
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13.1.2. Conceptul de dimensiune 


Dimensiunile au următoarele caracteristici: 
furnizează informaţii descriptive despre fiecare măsură ; 
sunt esenţiale pentru analiză; 
într-un cub n-dimensional o dimensiune este reprezentată printr-o axă; 
într-o schemă stea dimensiunile sunt tabele care se ed radial in juzal tabelei de 
fapte si se mai numesc tabele de dimensiuni (dimension tables). 
O dimensiune contine mai mulţi membri. Un membru este “un nume distinct sau un 
identificator. folosit pentru a determina Pa pozijia: unui element de dară (in schema stea apare sub 


să nu fie inclus într-o ierarhie desee. In dimensiunea Produs membra 
este inclus in nici o ierarhie (figura 13.2). 


IRR: 


Fig. 13.2. Un exemplu de cub n-dimensional pentru analiza vânzărilor 


De exemplu, un cub n-dimensional pentru analiza vânzărilor poate conține informaţii 
despre venituri (volumul vânzărilor) si cheltuieli (figura 13.2). Dimensiunile cubului sunt: 
Client, Produs si Timp. Atributele acestor dimensiuni pot varia în funcţie de specificul firmei 
analizate. Ca măsuri se pot defini: cantitatea vândută, volumul vânzărilor, costurile bunurilor 
vândute, numărul de clienți, etc. Pe baza acestor măsuri se pot determina alte măsuri (măsuri 
derivate) cu ajutorul formulelor (de exemplu profitul = volumul vânzărilor-costul bunurilor 
vândute). 

Granulaţia cubului n-dimensional este dată de granulația dimensiunilor (nivelul de 
detaliu al datelor stocate). De exemplu, dimensiunea Produs va stoca informații despre fiecare 
produs vândut. Cu acest model se poate realiza o analiză detaliată a vânzărilor şi anume 


DLL 
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Capitolul 13 
Baze de date multidimensionale 


| Desi majoritatea datelor stocate în cuburile n-dimensionale sunt mumerice, orice tip de 
| iste poate fi multidimensional. Multe instrumente OLAP oferă abilitatea de a popula cuburile 

„dimensionale cu date text. Datele numerice sunt mai potrivite pentru aplicaţiile OLAP, 
deoarece au o organizare multidimensională şi se pot agrega. Alte tipuri de date pot beneficia 


Volumul total al vânzărilor la nivel de lună, trimestru, anumită categorie de produ 
pentru un anumit client, oras, judeţ, ete. i ie i euis po 


13.1.3. Conci i i 
eptul de ierarhie z de organizarea multidimensională, dar apar probleme datorate agregării lor. Totuşi cele mai 
E einer ""- | uite date sursă, la nivel de întreprindere, sunt de tip şir de caractere. Din acest motiv, datele 
multe suni au o structură ierarhică. Timpul este o dimensi de tip şir de caractere vor deveni mult mai importante pentru instrumentele OLAP. Date cum 


ierarhică (ore, zile, săptămâni, uni, trimestre şi ani). În cele mai multe activități ale ug „fi: culoarea, adresa, tipul de ambalaj, tipul de client sunt factori esențiali pentru analiză. 


i ate la. s 
volumul vânzărilor lunare, pe trimestru, pe an, pentru a vedea care produse se vând mai bine. 131.4. Conceptul de măsură 


Piane de 
cmc ti dedil a fus 33 ete prezealată o ierarhie simetrică (ung: O măsură (variabilă) este un indicator de performanță prin care se poate analiza 
În glosarul de termeni OLAP se specifich t" patur s al ierarhiei, |. performanța activități modelate. Valorile unui indicator se modifică continuu. Pentru fiecare 

p e memelanilor pot florgonisi 3. | combinatie posibilă între dimensidni, există san i valodre corespunzioare a indiceforilor 
ecce A e E E A 
i e Marle anuari (D, Februeiid | cuci (de exempl: cantitatea vândută, volumul vtnzăciloe) atunci tributul seste ii 


Părinte se numește membru radăcină (root). În figura 13.3 ina i indicator. 
Membrii care nu au copii sunt numiţi frunza. Torahi „embru AP este rădacina ierarhii. Indicatorii pot fi clasificați in: 
care ţi frunză. lerarhiil inet poti olent ms 
exemplu în dimensiunea Timp există o ierarhie simemug POL fi simetrice sau asimetrice. De = indicmori de baza (de exemplu: volumul vânzările, cantitatea vândut, 
ntr-o dimensiune pot exista mai multe ierarhii. Alegerea niveluiilor i i | cupei i d oq Du 
Super sui agregare este inporent peu înjelegerea si abilitatea de (RE putem de > reri derivați care se obțin prin combinarea indicatorilor de bază (de exemplu 
m nivel de detaliu, un nivel de agregare complet dar multe nivel... oja eee cus dai do Ralph Kimball in cartea sa "The Data Warehouse 


Toolkit" şi anume după posibilitatea indicatorilor de a se insuma după dimensiuni: 

indicatori care se pot insuma după toate dimensiunile. De exemplu, volumul 

vânzărilor se poate calcula pentru o categorie de produse sau pentru o anumită regiune 
sau pentru a anumită perioadă de timp. 

- indicatori care se pot însuma numai după unele dimensiuni. De exemplu, numărul de 
clienţi, deoarece se poate calcula numărul de clienți într-o anumită perioadă de timp 
sau pentru o anumită regiune, dar nu este aditiv după dimensiunea Produs. 

- indicatori care mu se pot însuma după nici o dimensiune (de exemplu profitul 


marginal). 


13.1.5. Conceptul de multicub 


Întrebarea care apare este dacă se poate adăuga un număr nelimitat de dimensiuni la 
un cub n-dimensional şi dacă pentru modelarea unei activităţi complexe este suficient un 


singur cub n-dimensional. 

într-o i i "s În multe aplicaţii OLAP se utilizează date din mai multe domenii de activitate (de 

dimensiuni si ce tipuri de cal i jūnijs. exemplu activitatea financiară şi activitatea de marketing sau activitatea de producție şi 

iu = multiple dimensiuni şi multiple ^ » xtivitatea de desfacere). În aceste cazuri, se utilizează mai multe cuburi n-dimensionale sau 

a unui cub n-dimensional sau hypercub. Structuri multicub. Prin utilizarea structurii multicub este posibil de a integra seturi de date 

O celulă într-un cub i ită de i EI r. eterogene, Problema care apare în proiectarea unei structuri multicub este legată de modul 
Luciae, Unele celule conțin date de intrare cum ar fi vânzările zilnice, ade | "im Se realizează legitur între euburile n-dimensionale, 

e Datele multidimensionale sunt imprástiate (conceptul de fmprágtiere este frecvent 


conțin date derivate. Valorile datelor derivate sunt definite cu aj 
cu ajutorul formu h 
" nior. asociat cu datele multidimensionale si a fost utilizat cu semnificaţia de valoare lipsă, valoare 
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inaplicabilă si valoare zero) şi celulele de date nu sunt distribuite în mod egal în spaţiul 
multidimensional. Proiectanfii de instrumente OLAP au adoptat o varietate de strategii pentru 
a trata fenomenul de fmprástiere. 

În aplicaţiile mulricub, proiectantii descompun baza de date multidimensională într-un 
set de structuri multidimensionale, fiecare fiind compusă dintr-un subset de dimensiuni ale 
bazei de date. Aceste structuri multidimensionale au diferite denumiri (variabile — Oracle 
Express, Pilot; structuri — Holos; cuburi — Microsoft OLAP). 


13.2. Modele de date multidimensionale 


La ora actuală, multe firme utilizează si dezvoltă propriile modele de date 
multidimensionale. De asemenea, diferite comitete de standardizare au definit propriile 
modele multidimensionale . 

Cercetători din diferite domenii de aplicaţii au propus o serie de modele 
multidimensionale, dar fiecare model prezintă o viziune proprie a cerințelor analizei 
imensionale, o terminologie şi un formalism propriu. Multe dintre modelele 

multidimensionale propuse sunt modele logice (de exemplu modelul lui Kimball) şi numai 
câteva pot fi considerate pur conceptuale si anume: modelul lui Golfarelli (Dimensional-Fact 
Model), modelul lui Blaschka (multidimensiona/ER (M/ER)) si modelul lui Tryfona (starER). 

Modelul lui Golfarelli este un model conceptual propus in special pentru depozite de 
date, dar poate fi utilizat si pentru baze de date multidimensionale. Modelul este o colecţie de 
scheme fapt structurate arborescent, ale căror elemente componente sunt: faprele, atributele, 
dimensiunile şi ierarhiile. 

Modelul M/ER este o extensie a modelului entitate-asociere si : 

=. oferă un set de operaţii OLAP de bază ; 

-- modelează comportamentul sistemului OLAP prin diagramele de stare; 

- oferă un cadru pentru generarea automată a schemei logice a bazei de date cu un 
instrument OLAP (Informix Metacube şi Cognos Powerplay); 

- permite reprezentarea ierarhiilor multiple. 

Modelul StarER este un model de date conceptual care combină construcțiile 
modelului entitate-asociere cu structura stea. Este singurul model care se referă la asocierile 
de tip (m:m) între fapte și dimensiuni (prin indicarea cardinalitàfii). Elementele constructive 
ale modelului sunt: faptele, entitafile, asocierile între entităţi şi fapte (1:1, 1:m, m:n) $i 
atributele (proprietăţi statice ale entităţilor, asocierilor sau faptelor). 

Nici unul dintre aceste modele nu tratează măsurile derivate ca parte a modelului 
conceptual. Modelul lui Golfarelli şi modelul starER se referă la aditivitatea măsurilor prin 
reprezentarea în mod explicit a setului de operatori de agregare ce pot fi aplicaţi pe măsurile 
neaditive. De asemenea, toate modelele oferă o notație grafică. 

În tabelul 13.1 s-a realizat o evaluare a modelelor multidimensionale conceptuale 
prezentate anterior. 

La ora actuală nu există nici un model de date multidimensional conceptual acceptat în 
unanimitate. Un astfel de model este totuşi necesar pentru a servi ca o fundamentare pentru 
standardizare si cercetarea viitoare. 

Aşa cum s-a precizat la începutul acestui paragraf, multe din modelele 
multidimensionale propuse sunt modele logice - extensii ale modelului relajional. Cel mai 
cunoscut model multidimensional logic este modelul lui Kimball sau schema stea. În canes 
„The Data Warehouse Toolkit, Practical Techniques for Building Dimensional Dat 
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Warehouses”, Ralph Kimball defineşte schemă stea: „o reprezentare intuitivă a cubului de 
date n-dimensional într-un mediu relafional". 


T Tabelul 13.1. Analiză comparativă a modelelelor conceptuale 


Criterii de evaluare Modele conceptuale: 
Golfarelli MIER | serer 
Modelarea asocierilor (m:m) între fapte şi | Nu Nu Da 
dimensiuni 
Nu Nu [Xu 
Da Nu Da 
Da Da Da 
Nu Da Nu 
Modelarea comportamentului sistemului | Nu Da Nu 
OLAP 
Notaţii grafice Da Da | Da 
Limbaj de interogare propus | algebră algebră m 
Arhitectura implementată ROLAP/MOLAP | ROLAP/MOLAP | ROLAP 
Posibilitatea de generare automată a|Nu Da [Xu 
schemei logice a bazei de date i 


Schema stea contine o tabelă centrală si un set de tabele de dimensiuni aranjate într-o 
manieră radială, în jurul tabelei centrale. Fiecare /abeld de dimensiuni reprezintă o 
dimensiune a activităţii analizate, în timp ce tabela centrală reprezintă conținutul cubului de 
date. Schema este foarte asimetrică. Există o tabelă dominantă în centrul schemei, singura 

tabelă din schemă cu multiple joncțiuni, prin care se conectează la celelalte tabele. Această 
tabelă se numeşte rabela de fapte (fact table). Celelalte tabele au numai o singură joncțiune. 

- prin care se leagă la tabela centrală şi se numesc fabele de dimensiuni sau dimensiuni 

- (dimension table). Schema stea reduce numărul de joncfiuni între tabele, ca urmare a 

procesului de denormalizare. Nu există nici o informaţie despre nivelurile ierarhice stocate în 
structura schemei stea. În plus, reprezentarea unei dimensiuni printr-o singură tabelă conduce 
la date redundante. În mediile cu depozite de date, aceasta nu cauzează nici o problemă, 

-. deoarece datele sunt în cele mai multe cazuri interogate. 

Tabelă de fapte are următoarele caracteri: 

Li - confine un număr foarte mare de tupluri (posibil milioane). Numărul de tupluri din 
tabelă reprezintă de fapt produsul cartezian al dimensiunilor. 

- dimensiunea ei creşte dinamic, în funcţie de volumul de date încărcate la fiecare 
ciclu de actualizare a bazei de date, precum si în funcție de volumul de date 
istorice stocate în baza de date. 

- este tabela care reflectă performanța activităţii analizate. 

- cheia primară a tabelei este o cheie compusă, formată din cheile primare ale 
tabelelor de dimensiuni. De exemplu, cheia primară a tabelei de fapte Unit este 
formată din atributele canal id, produs id, client id, luna id (figura 13.4). De 
asemenea, fiecare din aceste atribute sunt chei externe. 

- este normalizată si realizează de fapt o legătură indirectă între dimensiuni. 
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anima 134 se prezintă un exemplu simplificat de schemă stea cu abela de 


data sfarsit aa 


Dimensiunea Canale 
SucaL jd 


canal dse 
1o! canal jd 
total canal dec 


TT 


Fig. 13.4. Un exemplu de schema stea E 


ce conţin informaţii 
(preţ unitar, cost unitar, cantitatea vândută) utilizaţi în analiza vânzărilor 
Avantajele schemei stea: 
* este uşor de construit; 
feci cu exactitate modul cum înțeleg utilizatorii activitatea modelată; 
furnizează o performanță ridicată pentru cereri OLAP, prin reducerea ermirulu de 
Joncțiuni; 


permite modelarea unor structuri multidimensionale complexe; 
toi indicatorii de performanţă ai acivititil modelate sunt stoca în zabela de pt 
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Fig. 13.6. Tuplurile tabelei Clienti 


Dezavantajele schemei stea: 

- este o schemă inflexibilă. Adăugarea unei noi dimensiuni în schemă, poate duce la 
modificarea granulaţiei tabelei de fapte; 

= confine date redundante ce conduc la creşterea riscului de inconsistenfà a datelor; 

- pentru a permite analize complexe, trebuie să includă multe tabele de agregate; 

- are o scalabilitate limitată; 

- este dificilă joncţiunea între tabelele de fapte. 


Schema fulg de zăpadă este o variantă a schemei stea. Este rezultatul descompunerii 
unei dimensiuni sau a mai multor dimensiuni care au ierarhii. Relaţiile de tip (m:l) între 
membrii unei dimensiuni se descompun în tabele separate formând o ierarhie de tabele. 
Schema fulg de zăpadă vizualizează structura ierarhică a dimensiunilor. Diferenţa esenţială 
faţă de schema stea este că dimensiunile sunt normalizate. Principala motivaţie a normalizării 
este spaţiul de stocare. Dacă ierarhiile se păstrează în tabele separate, se consideră că spaţiul 
de stocare se reduce consistent. Totuși Ralph Kimball în lucrarea sa "Practical Techniques for 
Building Dimensional Data Warehouse” încearcă să demonstreze contrariul. El afirmă că 
eforturile de a normaliza tabelele, în scopul de a reduce spaţiul de stocare, sunt inutile şi 
consumatoare de timp. Normalizarea dimensiunilor reduce cu mai puțin de 1% spațiul total de 
stocare, iar vizualizarea datelor este mai dificilă, implicând un număr mai mare de joncţiuni 
între tabele. Mulţi proiectanți nu consideră că salvarea spațiului ar fi o cerință majoră în 
selectarea tehnicii de modelare. 

Avantajele schemei fulg de zăpadă: 

- este mai flexibilă si se pot defini cerințele utilizatorilor mult mai bine; 

~ structura normalizată a dimensiunilor este mai uşor de modificat; 

- este folosită de multe instrumente OLAP; 

- reduce redundanja datelor; 

- îmbunătăţeşte performanţa operaţiilor de drill down şi roll up. 


Dezavantajele schemei fulg de zăpadă: 
este mai complexă decât schema stea; 

= scade performanţa la interogare, deoarece sunt folosite multe joncjiuni; 

- schema este mai dificil de înţeles de către utilizatori, fiind mai apropiată de 
modelul entitate-asociere. 


Modelele stea si fulg de zăpadă, precum si variantele lor au devenit o reprezentare 
logică bine cunoscută a structurilor de date multidimensionale, in sistemele relafionale. 
Selectarea unei scheme potrivite ţine cont de raportul dintre costul de stocare şi performanța 
interogării. Schema stea oferă performanţe mai bune la interogare, datorită unui număr mic de 
operaţii de joncțiune între tabela de fapte şi tabelele de dimensiuni, dar costul de stocare este 
mai ridicat. Schema fulg de zăpadă implică mai multe operaţii de joncțiune, dar presupune o 
capacitate de stocare mai mică. Pentru ambele modele există o mulțime de variante. Schema 
stea de zăpadă (starflake) sau schema fulg de zăpadă degenerată (degenerated snowflake) 
sunt o combinaţie de schemă stea si schemă fulg de zăpadă, în care o parte a tabelelor de 
dimensiuni sunt denormalizate. 

În schema constelație (fact constellation) există tabele de fapte suplimentare cè 
stochează date agregate. O constelație este o colecţie de stele şi constă dintr-o stea centrală 
înconjurată de alte stele. Steaua centrală conţine datele la nivel atomic, iar celelalte stele 
conţin date agregate. Steaua centrală se leagă de celelalte stele prin atribute dimensionale 
(figura 13.7). 


n 


TEUTNQ Ufa Case ver M sia 


Fig. 13.7. Schema constelație 


ILL! 


13.3. Utilizarea limbajului SQL pentru cereri OLAP. 
| Operatorii ROLLUP şi CUBE 


Cererile analitice (OLAP) sunt cereri formulate adesea de către manageri si analişti şi 
presupun agregarea complexă a datelor. Cererile OLAP folosesc date de detaliu şi/sau 
derivate, istorice şi/sau curente, iar natura lor nu este întotdeauna previzibilă. De asemenea, 
pot accesa milioane de înregistrări și pot executa o mulțime de parcurgeri ale tabelelor, 
joncţiuni si agregări (în cazul sistemelor ROLAP). 

Utilizatorii pot executa următoarele operaţii OLAP: 


- Slice şi dice sau selecţii în cub. ; 
- Drill down / roll up ce utilizează ierarhiile din dimensiuni şi măsurile pentru 
z agregări sau de-agregări; 
- Drill across ce combină mai multe cuburi cu una sau mai multe dimensiuni 
comune (joncțiunea de cuburi); 


- Ranking sau top/bottom n ce permite analize de tip “primii n" sau “ultimii n” după 


i Pivot sau rotirea unui cub pentru a pune în evidență alte aspecte analitice. 

i Unele operaţii OLAP pot fi executate uşor şi cu ajutorul limbajului SQL (de exemplu 
T operaţia roll up), altele nu. De exemplu, în tabela Clienti (figura 13.6) există următoarea 
ierarhie: client— oras— judet— total. clienti. Se poate utiliza limbajul SQL pentru a agrega 
valorile măsurii cantitatea la diferite nivele ale acestei ierarhii. 

| In figura 13.8 se realizează o operație de roll up sau de agregare a măsurii cantitatea la 

nivelul oras din ierarhie, iar în figura 13.9. se realizează o operaţie de tip pivor (rotirea 
^ cubului) care permite vizualizarea datelor din cub după dimensiunea Timp şi Produs. S-a 
utilizat instrumentul Oracle OLAP Worksheet 
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În 1997, Gray propunea doi operatori CUBE şi ROLLUP pentru agregarea complexă a 
datelor stocate în baze de date relaţionale. Limbajul SQL standard 1999/2003 a inclus aceşti 
operatori. De asemenea, multe SGBDR permit deja acești operatori (Oracle, SQL Server). 
Vom exemplifica modul de utilizare a acestor operatori, utilizând SGBDR Oracle 10g şi 
instrumentul SQL* Plus. Sc consideră tabela Persoane cu următoarea structură si tupluri: 


SQL» dese persoane 
Name Null? Type 
CODP — NOTNULL NUMBER) 
NUME VARCHAR2(30) 
FUNCTIA VARCHAR2G) 
AN PROM VARCHAR2(4) 
CODCAT VARCHAR?) 
SQL» select codp, nume, functia, codcat from persoane; 
CODP NUME FUNCTIA — CODCAT 

C. Mimtean Mihaela C IE 

E Jonescu Simona A IE 

3 Dumitru lon P IE 

4 Lungu Diana L ca 

5 Marin lon " CIR 

6  PopescuDiana — 4 IE 

7 Popesculon c cm 


Dacă dorim să afişăm pentru fiecare catedră, numărul de persoane corespunzător 
fiecărei funcţii, se execută următoarea cerere: 


SQL> select codcat, functia, count(codp) numar from persoane group by codcat, functia; 


CODCAT FUNCTIA NUMAR 
IE A 2 
IE c 1 
[3 T. 1 
CIB [^ 1 
CIB L 1 
CIB T L 


numărul de 


Dacă dorim să afişăm pentru fiecare catedră şi persoane angajate, precum 
ROLLUP în clauza GROUP BY: 


şi numărul total de persoane angajate, vom utiliza operatorul 


SOL> select codcat, functia, count(codp) numar from persoane 
group by rollup(codcat, functia); 


am 


CODCAT FUNCTIA NUMAR c 1 
E Dc E it ag P H 
IE 4 2 4 
IE € 1 € 1 
IE P 1 CIB L 1 
IE 4 jas P 1 
CIB € 1 CIB 3 
CIB i T 
CIB P 1 În acest caz, nu se produce un total general (total după toate dimensiunile). Dacă in 
CIB 2 ROLLUP sunt specificate N atribute, atunci se produc N+1 tipuri de subtotal. 
7 


Operatorul CUBE realizează toate tipurilor posibile de agregare (totaluri pentru fiecare 
Operatorul ROLLUP generează subtotaluri. Primele trei tupluri sunt identice cu — [| combinaţie posibilă de dimensiuni). Cubul poate fi un cub complet sau un cub parțial. Pentru 

primele trei tupluri ale cererii ce utilizează numai clauza GROUP BY. Al patrulea tuplu este — | “exemplificare se consideră tabela Persoane şi se doreşte să se afişeze : 

un subtotal al atributului "funcfia" (apare valoarea null în coloană “Funcţia”). În realitate nu - pentru fiecare catedră, numărul de persoane corespunzător fiecărei funcţii (adică 

sunt valori nule în această coloană (este un artificiu al operatorului ROLLUP). Următoarele numărul de profesori, numărul de conferențiari, numărul de lectori, numărul de 

trei tupluri sunt tupluri de detaliu, iar tuplu următor este un alt subtotal după atributul asistenţi şi numărul de preparatori pentru fiecare catedră); 


“funcţia”. Ultimul tuplu este un total general. pentru fiecare catedră, numărul de persoane angajate; 
Următoarea cerere este echivalentă cu cererea ce utilizează operatorul ROLLUP: 1 numărul total de persoane corespunzător fiecărei funcţii (adică numărul total de 
profesori, numărul total de conferenfiari, numărul total de lectori, numărul total de 
SQL> select codcat, functia, count(codp) numar from persoane asistenţi, numărul total de preparatori); 
group by codcat, functia E - numărul total de persoane angajate. 
union 
select codcat, '', count(codp) numar from persoane group by codcat, ' 3 SQL> select codcat, functia, count(codp) numar from persoane 
union I group by cube(codcat, functia); 


select '', '', count(codp) numar from persoane group by '', ''; : 
CODCAT FUNCTIA NUMAR 


CODCAT FUNCTIA NUMAR 


= & 7 

7 i A å 

CIB 3 E c 2 
CIB c 1 3 L 1 
CIB L 1 3 # 2 
CIB P ri IE 4 
IE 4 IE A 2 
IE A 2 IE c 1 
IE C 1 uE P 1 
IE P 1 Cip 3 
-CIB E 1 

Citirea acestei cereri este mai dificilă. De asemenea, tabela se parcurge de mai multe CIB L 1 

ori. Operatorul ROLLUP, mai concis şi mai ușor de citit, este mai eficient (mai ales pen — | cus P 1 


seturi mari de date), deoarece tabela se parcurge o singură dată. Sunt posibile şi operații rollup 
parţiale: 


É Se poate utiliza funcția GROUPING care face distincţie între valorile null curente si 
Cele ce rezultă prin agregare, returnánd o valoare 0 pentru primul caz şi o valoare 1, când este 
detectat un subtotal. 


SQL> select codcat, functia, count(codp) numar from persoane 
group by codcat, rollup(functia); 


up 


SOL» select codcat, functia, count(codp) numar, grouping(codcat) t, 


CODCAT FUNCTIA NUMAR rouping(functia) f from persoane group by cube(codcat, functia); 
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CODCAT 


7 Lcd —— 

4 2 Ed 7 
Ü 2 $ 9 2000 2 
L 1 Lass d 2004 2 
P 2 paes 2005 3 
IE 4 oed 4 2 
IE A 2 0 0 4 2005 2 
IE (^ 1 D. cud c 1 
IE P 1 0 0 C 2» 1 
CIB 3 a ud L ^ 
CIB È 1 o o LM 1 
CIB L 1 rm P $ 
CIB P 1 0 0 P 2000 - 
P 2005 1 
Funcţia GROUPING poate fi utilizată, de asemenea, pentru filtrarea tuplurilor: E - z 

| E 2000 
SQL> select codcat, functia, count(codp) numar, grouping(codcat) t, IE 2004 1 
grouping(fioictia) f from persoane group by cube(codcat, functia) IE 2003 2 
having groupingícodcar)-0 and grouping(functia)-0; | E 4 i 

IE A 205 
CODCAT FUNCTIA NUMAR T F 4 E c 1 
Po ME IE C 20% 1 
IE 4- Xf dvd IE P 2 
1E € I4 4008 a E P 200 2 
IE P an e CIB 3 
CIB c 1 0 0 CIB 2004 1 
CIB L EX E; CIB 2005 2 
CIB P M Aso CIB 4 1 
CIB 42005 1 
Se pot realiza agregări complexe care presupun utilizarea operatorilor ROLLUP si CIB L 1 
CUBE cu mai multe atribute de grupare. De exemplu se utilizează operatorul CUBE cu trei CIB L 200 1 
atribute: codcat, funcția şi an. prom. CIB P 1 
cB P 2005 1 


SQL> select codcat, functia, an prom an, count(codp) numar from persoane 
group by codcat, functia, an prom; 


CODCAT FUNCTIA AN NUMAR 


Clauza GROUPING SETS permite definirea de grupuri multiple într-o singură cerere. 
Pentru fiecare grup definit, Oracle realizează toate tipurile de agregări, apoi combină 
rezultatele utilizând operatorul UNION ALL în mod implicit. Se realizează astfel o agregare 
mai eficientă a datelor, precum şi o analiză mai complexă a datelor: 


IE 4 2005 1 
IE c 2004 1 SQL» select codcat, functia, an. prom an, couni(codp) numar from persoane 
IE P 2000 2 group by grouping sets 
da i, A i ((codcat, functia, an prom), (codcat, an prom), (functia, an prom); 
CIB P 2005 1 CODCAT FUNCTIA AN NUMAR 
SQL> select codcat functia, an. prom an, count(codp) numar from persoane IE P 2000 2 

group by cube(codcat, functia, an prom); IE € 2004 1 

IE 4 2005 1 
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CIB L 2004 1 
CIB 4 2005 1 
CIB P 2005 1 
IE 2000 2 
IE 2004 1 
IE 2005 1 
CIB 2004 1 
CIB 2005 2 
A 2005 2 
c 2004 1 
L 2004 1 
P 2000 2 
P 2005 1 


O alternativă ineficientă este exemplul următor: 


SQL» select codcat, functia, an prom an, count(codp) numar from persoane 
group by codcat, functia, an prom 
union all 
select codcat,null, an prom an, count(codp) numar from persoane 
group by codcat, an prom 
union all. 
select null, functia, an prom an, count(codp) numar from persoane 
group by functia, an. prom; 


Operatorul CUBE(a,b,c) este echivalent cu clauza GROUPING SETS((a.b,c). (a.b). 
(a,c), (b,c), (a), (b), (c), 0). Operatorul ROLLUP(a,b,c) este echivalent cu clauza GROUPING 
SETS (abc), (a,b), (a), 0) 
„Operatorul CUBE se utilizează în special pentru a realiza agregări complexe a datelor 
relaţionale si a stoca apoi aceste agregate în baze de date multidimensionale. 


13.4. Integrarea tehnologiei relationale cu tehnologia 
multidimensională 


În pagina Web a firmei IBM, conceptul de Business Intelligence (inteligenţa afacerii- 
BI) este definit astfel: “BI inseamnă utilizarea tuturor datelor de e5 poa pon pentru 
a îmbunătăţi procesul decizional. BI presupune accesul la date, analiza lor şi descoperirea de 
noi oportunități de utilizare a lor.” 
Principalele obiective ale unui sistem BI sunt: 
- uice soluții cu eux i scăzute ce oferă avantaje firmei; 
- să permită acces rapid şi uşor la informaţiile firmei i variat 
Pies rapid şi uşor rmajiil i pentru un număr mare şi 
- să ofere suport pentru tehnologiile modeme (tehnici de analiză complexe- 
instrumente OLAP, instrumente de tip data mining, etc); 
- să ofere un mediu de operare deschis si scalabil. 
La ora actuală există o gamă variată de produse software pentru a dezvolta soluţii Bl: 


382 


Instrumentele de raportare. Cele mai multe organizaţii utilizează instrumente de 
raportare nu foarte complexe pentru a accesa datele stocate în depozitele de date. Aplicațiile 
* BI construite cu astfel de instrumente: 

-  fumizează rapoarte statice sau parametrizate destinate unui număr mare de 
utilizatori din organizaţie; 

- oferă puţine facilităţi analitice; 

- utilizează de regulă baze de date relafionale (depozite de date/centre de date) şi 
limbajul SQL. 


Instrumentele de analiză şi interogare ad-hoc. Aplicațiile BI construite cu astfel de 
instrumente: 

- permit un nivel ridicat de interacţiune cu utilizatorul (tehnici de navigare şi selecţie 
a datelor); 

- utilizează de regulă baze de date relafionale si limbajul SQL; 

- oferă unele facilităţi analitice; 

- utilizează adesea ca model de date multidimensional logic schema stea sau fulg de 
zăpadă; 


: Instrumentele OLAP (de analiză multidimensional). Instrumentele OLAP utilizează 

tehnici analitice simple (analiza multidimensională a datelor) pentru a analiza seturi mari de 
7 date. Cele mai multe aplicaţii BI construite cu instrumente OLAP (de exemplu pentru: analiza 
* costurilor, analiza profitului, analiza vânzărilor, analize de marketing, etc) utilizează baze de 
- date multidimensionale ce permit cereri complexe (de exemplu "Care a fost procentul de 
* creştere a volumului vânzărilor anul acesta faţă de anul trecut, pentru fiecare din primele 10 
7 produse vándute?"). Utilizarea bazelor de date multidimensionale este costisitoare şi sunt 
- destinate de regulă managerilor si analistilor (deci unui număr restrâns de utilizatori). 


m——— HÀ 


= Aplicațiile ce utilizează instrumente de planificare (de exemplu aplicaţii de 
7 financiară şi de planificare a bugetului la nivelul organizaţiilor) sunt foarte diferite de 
L aplicaţiile ce utilizează instrumente de interogare și raportare, deoarece ele generează noi date 
" utilizând modele pentru previziuni, scenarii de tip “what-if”, etc. Aceste aplicaţii permit 
7 utilizatorilor: să analizeze performanţele anterioare si să răspundă la întrebări cum ar fi: “Care 
` produse sunt cele mai profitabile?", să modeleze efectele fluctaţiilor valutei asupra 
„veniturilor, costurilor si profitabilităţii, să stabilească bugete alternative și planuri de investiții, 
F etc. 
La ora actuală există două tendințe în aplicațiile BI: 

E O corelare cát mai bună între activitatea de analiză şi cea de planificare. Aplicațiile 
` Bl trebuie: 

- - să furnizeze acces rapid unui număr mare de utilizatori, distribuiți geografic, la un 
stoc de date centralizat; 

- să permite agregarea complexă a datelor; 

- să utilizeze facilitățile oferite de Internet. Existenţa unui catalog de metadate 
centralizat şi a unui stoc de date centralizat poate să le ofere utilizatorilor o viziune 
comună asupra datelor. Toţi utilizatorii trebuie să acceseze acelaşi model de date și 
aceleaşi date. 

Convergen(a aplicaţiilor BI cu aplicaţiile operaționale (tranzac[ionale). Activităţile 
operaționale şi cele de analiză constituie nucleul activităţii unei firme, independent de 
mărimea ei, domeniul de activitate, forma legală. Informaţiile despre vânzări, producție şi 
costuri pot fi înregistrate și gestionate în una sau mai multe baze de date, folosite pentru 
scopuri operaționale. Activităţile operaționale se execută la un interval relativ constant. Datele 
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a 
sunt citite şi actualizate frecvent şi reprezintă o fotografie curentă a ceca ce se întâmplă în 
firmă. Fiecare cerere foloseşte un volum mic de informaţii, iar natura ei este in genera] 
previzibilă. 

Monitorizarea, evaluarea, compararea, planificarea şi alocarea strategică a resurselor 
sunt exemple de activităţi de analiză. Informaţia generată prin activităţile de analiză este 
orientată pe decizie, deoarece este într-o formă ce o face imediat utilizabilă în procesul 
decizional. Orientarea spre decizie a analizei este esenţială. Datele sunt mai mult citite decât 
actualizate în aceste activități. Cererile analitice folosesc date derivate şi natura lor nu este 
întotdeauna previzibil. Ca urmare a acestor diferențe, majoritatea firmelor folosesc 
instrumente diferite pentru cele două tipuri de activităţi. Astfel: 

= se asigură eficiență maximă în ambele activităţi, 

- se realizează o actualizare rapidă în activităţile tranzacţionale şi calcul rapid in 

activitățile de analiză. 

De asemenea, aplicaţiile analitice pot utiliza pentru stocarea datelor fie baze de date | 
relajionale (depozit de date/centru de date) sau baze de date specializate (de regulă I 
Adesea) Stocarea datelor se face într-o bază de date relafionalà atunci când: 

volumul de date este prea mare pentru a fi duplicat; 

- datele sursă se modifică frecvent şi este mai bine de a citi în timp real decât din 

copii; 

- se doreşte integrarea cu alte sisteme informatice relaționale existente; 

- organizația are o politică de neduplicare a datelor, pentru securitate sau alte 

motive, 

chiar dacă aceasta conduce la aplicaţii mai puţin eficiente. 

De asemenea, depozitele de date pot fi accesate de o mare varietate de instrumente de 
raportare şi interogare ce utilizează limbajul SQL. Totuşi limbajul SQL nu oferă facilităţi 
analitice complexe. 

La ora actuală există trei soluţii pentru a adăuga SGBDR-urilor facilităţi analitice 
complexe: 

- integrarea procesării multidimensionale în sistemul de gestiune a bazei de date 

relajionale, fie prin extinderea limbajului SQL (de exemplu operatorii ROLLUP şi 
CUBE) sau prin adăugarea funcţionalităţi multidimensionale în nucleul SGBD- 
ului (de exemplu Oracle 10g cu opţiunea OLAP); 

- executarea în mai mulți paşi a comenzilor SQL (multipass SQL). Instrumentul 

OLAP realizează o serie de comenzi SELECT, în care ieșirile comenzilor 
sic we amant E tauri ol martina die 


E iara debris dm ee coreene en ee de pe 
intermediar, unde este realizată procesarea multidimensională. 


Bazele de date multidimensionale oferă facilităţi analitice complexe, o performanţă 
mai bună la interogare, dar întreținerea unei astfel de baze de date este costisitoare. O bază de 


date multidimensională cere datelor, un proces costisitor care poate cauza şi 0 
întârziere semnificativă în utilizarea datelor de către analişti. De asemenea, se cere modelarea 


este uşor pentru instrument de a manipula 
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multidimensionale si de a face calcule corecte şi complexe. Stocarea fizică a datelor 
multidimensionale, precum și fenomenul de impräştiere sunt preocupări majore, în domeniul 
bazelor de date multidimensionale. O tehnică de stocare a datelor optimă ar trebui să ţină cont 
de ini factori dinamici şi anume: 
profilul datelor si volumul lor (numărul de dimensiuni şi numărul de membrii ai 
dimensiunilor, tipurile de date), 


-~ fenomenul de împrăștiere, 

~ frecvenţa de modificare a surselor de date (cât de des vor fi actualizate bazele de 
date multidimensionale), 

- frecvența de modificare a datelor multidimensionale (de exemplu pentru analiza de 
tip "what if^), 

- frecvenţa de modificare a modelului multidimensional, accesul concurent, etc. 

Utilizarea separată a celor două tehnologii implică: 

- - două baze de date (baza de date relaţională şi baza de date multidimensională) ce 
trebuie gestionate separat; 
dicţionare de mctadate separate; 
modele de securitate separate pentru BDR şi BDMD; 


- instrumente de administrare separate; 

- mai mult personal pentru administrare ; 

- o interfaţă OLAP API special proiectată pentru a accesa baza de date 
multidimensională;, 

- replicarea datelor din baza de date relațională în baza de date multidimensională; 

- actualizarea datelor în două etape mai întâi depozitul de date, apoi baza de date 
multidimensională. Acest proces este consumator de resurse şi timp. De asemenea, 
creşte perioada de timp dintre momentul actualizări surselor de date şi momentul 
actualizări bazei de date multidimensionale; 


Din perspectiva unui administrator de bază de date: 

- se utilizează trei tehnologii diferite (instrumentul de integrare a datelor, tehnologia 
relafionalà si tehnologia OLAP), 

- trebuie gestionate trei dicționare de metadate 

- $i există două stocuri de date (depozitul de date relațional şi baza de date 
multidimensional&). 


m: De exemplu, aplicaţiile BI construite cu produse Oracle (anterioare versiunilor 9i şi 
ilizau: 

- Oracle Express Server/Oracle Personal Express, un server OLAP (datele sunt 
stocate într-o bază de date multidimensional); 

- Oracle Express Administrator un utilitar grafic pentru definirea, întreținerea si 

bazelor de date multidimensionale Express; 

~ Oracle Express Relational Access Manager (RAM) care permite ca instrumentul 
Express Analyzer să acceseze datele stocate într-o bază de date relațională 
(configurată cu instrumentul Relational Access Administrator-RAA); 

- Oracle Warehouse Builder pentru a crea depozitul de date si pentru a se încărca 
date în depozitul de date. Oracle Warehouse Builder include si instrumentele ETL 
(instrumente de ', transformare şi încărcare a datelor) (figura 13.10.) . 

în 1972 cile alice şi faciie de gestiune à datelor au fost integrate inan 

limbaj, limbajul Express, destinat pentru aplicaţii de . După 30 de ani, limbajul 
Express rămâne una din principalele tehnologii OLAP folosite, conceptele şi modelul de date 


fiind neschimbate. În 1995 Oracle achiziţionează Express, iar în 2002 lansează Oracle; 


Release 2 OLAP care integrează toate facilităţile OLAP în baza de date relațională Oracle. 


Achizitie de date 


Fig. 13.10. Utilizarea tehnologici relaionale separat de tehnologia OLAP 


„„ „Oracle Express este un pachet software de tip sistem de gestiune a bazelor de date 
multidimensionale (SGBDMD) cu următoarele caracteristici: 


oferă un limbaj de manipulare a datelor foarte puternic; 
utilizează un model de date multidimensional; 
utilizează o arhitectură client/server (Oracle Express Server) 


Arhitectura pe componente a SGBDMD-ului Oracle Express este formată din (figura 


13.11): 


Nucleul care include limbajul Express; 

Utilitare pentru administrare (Express Instance Manager, Express Administrator. 
şi Relational Access Manager). Aplicațiile OLAP dezvoltate cu Oracle Express 
pot accesa direct date stocate în baze de date relafionale (depozite de date) cu 
ajutorul lui Relational Access Manager (RAM). Express Instance Manager este un 
utilitar orientat Java ce utilizează comunicaţii CORBA şi care gestionează si 
configurează servicii şi sesiuni de lucru. Fiecare instanţă Express Server este un 
serviciu ce permite utilizatorilor acces la bazele de date multidimensionale sau 
aplicaţii prin interfeţe de tip SNAPI (Structured n-dimensional Application 
Programming Interface) XCA (Express Communications Architectures) sau 
Express Web Agent. De asemenea, Express Instance Manager permite 
modificarea parametrilor de configurare a instanţelor Express. 

Instrumente de dezvoltare. Oracle Express Analyzer este un instrument OLAP care 
permite utilizatorilor să selecteze, afişeze şi analizeze datele stocate în baza de date 
multidimensională. Oracle Express. Objects este un instrument OLAP ce permite 
crearea de aplicaţii OLAP si briefing-uri complexe care pot fi rulate si in Express 
Analyzer, precum si realizarea de programe în limbaj Express, prin care se 
controlează comportamentul aplicaţiei, Aplicațiile OLAP dezvoltate cu Oracle 
Express Objects accesează datele stocate în baze de date multidimensionale sau 
baze de date relafionale. 


Elementele componente ale unei baze de date Express sunt (figura 13.12.): 
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- Dimensiunile. Primele obiecte care trebuie create într-o bază de ze 


- Relațiile. O relaie descrie corespondența inre valorile usei dizacsi-i 
- Formulele. O formulā este ta obiect al bazei de date Expres 


- Obiectele compuse (composite). Un obiect compus este o secs 


- Modelele. Un model stochează un set de ecuații interdependee, sare 


- Programele. Un program corjine secvențe de comenzi 2 


-  Variabilele. O variabilă este un obiect al bazei de date Express ce socheazā iem. < 


matrice multidimensională ale cárei celule stochează dare. Tipr de ză si m5 
variabile indică datele pe cere le confine. Fiecare varisiilă ese orgzrizză ser 
dimensionată după una sau mai multe dimensiuni (max 32 de eesti). 
necesar ca toate variabilele să aibă aceeași dimensioni (së rer aces se 
de dimensiuni). 


ln tele led o dee cce 
incluse (embedded total dimension). 


altei dimensiuni din baza de date. Se pot utiliza relezile si pen: 2 
în dimensiuni. 


expresie. Valorile formulei sunt calculate ori de câte oñ 
Termenul de măsură este folosit pentru a referi variabile! 


combină valorile a două dimensiuni imprástiate. 


valorile unor variabile sau a unor dimensiuni. Modelele szat Ê 
calculele sunt complexe sau variabilele nu sunt aditive. 


manipulează datele multidimensionale. 


Instrumente de dezvoltare 


Express Expres Web 
Asalyzer iuter 


Nucleul (limbajul Express) 


Utilitare pentru administrare 


Express Instance || Express Reiatocal 
Manager Admiziscecr Access Manager 


Fig. 13.11. Arhitectura pe componente a lui Oracle Express 


Oracle Express Administrator se utilizează pentru a crea gi sămizisca baze de due 


Express. Pentru a crea o bază de date multidimensională se parcurg uxmátoc: pesi: 


- definirea dimensiunilor bazei de date; 
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~ definirea măsurilor (variabile, relaţii, formule); 
- definirea seturilor de valori; sri s 
~ definirea programelor si a modelelor de analiză; 


Dre cae nominate 


Fă 


componente ale unei baz 


MEA 
e de date Expre: 


Baze de date multidimensionale 


În figura 13.13. se prezintă un exemplu simplificat de bază de date Express. În figura 
13.14 se prezintă un exemplu de aplicaţie OLAP construită cu ajutorul instrumentului Oracle 
Express Analyzer. Aplicația permite utilizatorilor: 

- să execute cu uşurinţă operaţii OLAP ; 

- shvizualizeze ierarhiile din dimensiuni; 

- să vizualizeze datele analizate sub formă grafică si tabulară, etc 


Banji t S D O | ores] Seene ozn tvm | Wrote 


Fig. 13.14. Exemplu de aplicație OLAP construită cu ajutorul instrumentului Oracle Express 
Analyzer 


13.4.1. Avantajele unui mediu integrat relational 
multidimensional 


Integrarea tehnologiei relagionale cu tehnologia OLAP permite realizarea de aplicaţii 
cu o funcționalitate ridicată, mai puțin costisitoare și care oferă un suport adecvat atât pentru 
activitatea de analiză cât şi pentru activitățile operaţionale. 

Va exista un singur stoc de date şi un singur dicţionar de metadate. De asemenea, 
trebuie implementată o singură politică de securitate, De exemplu Oracle 10g cu opțiunea 
OLAP realizează integrarea tehnologiei relajionale cu tehnologia OLAP. Oracle 10g utilizează 
baza de date relațională atât pentru aplicaţii operaționale cât şi pentru aplicaţii analitice. 
Datele necesare analizelor sunt valabile 24 de ore din 24. 

Opţiunea OLAP include un motor de calcul multidimensional ce permite analize foarte 
complexe pe datele stocate în spaţiul analitic şi are la bază tehnologia Express. Datele stocate 
în spaţiile analitice sunt manipulate cu ajutorul limbajului de manipulare OLAP (OLAP 
DML). Acest limbaj este echivalentul "multidimensional" al limbajului PL/SQL și extinde 
facilităţile analitice ale limbajului SQL. Include funcţii pentru analiza seriilor de timp (de 


exemplu funcția LAGO), funcţii financiare, funcții statistice, o mare varietate de metode de 
agregare (după nivelul din ierarhie, după anumiţi membrii, etc) 

Datele pot fi stocate în tabele (tabele de fapte şi tabele de dimensiuni) sub formă de 
schemă stea sau fulg de zăpadă sau în variabilele din spațiul analitic, iar utilizatorii pot accesa 
datele printr-o interfaţă OLAP (de exemplu instrumentul Oracle BI Beans ) sau cu ajutorul 
limbajului SQL (de exemplu instrumentul Oracle BI Discoverer) 


Spaţiul analitic (analytic workspace-AW) : 
- confine un număr de obiecte multidimensionale (dimensiuni, ierarhii, măsuri) si 
poate fi gândit ca o schemă multidimensională; 


> aparține unui utilizator si alți utilizatori pot avea acces la el; 

Într-o bază de date Oracle se pot crea mai multe spații de lucru analitice; 

Un spaţiu analitic în format standard este un spaţiu analitic construit cu un set specific 
de obiecte cum ar fi dimensiuni ierarhice, asocieri de tip părinte, asocieri de tip nivel. Fiecare 
obiect trebuie să fie definit cu un set de proprietăţi ce identifică rolul obiectului şi asocierile 
lui cu alte obiecte din spaţiu analitic. 


Analytic Workspace Manager (AWM) este un instrument de administrare utilizat 
pentru: 

- a crea spaţii analitice în format standard ce pot fi accesate de aplicaţiile construite 
cu Oracle BI Discoverer, Oracle BI Spreadsheet Add-In, Oracle BI Beans. În 
figura 12.15 este prezentat un spaţiu analitic în format standard creat cu AWM si 
care are denumirea GLOBAL. 

a actualiza spaţiile analiti 
a crea $i executa planuri pentru agregarea datelor; 
a crea măsuri derivate; 

Un utilizator care cunoaşte cerințele analitice si are acces la sursele de dăte poate 
construi un spațiu analitic cu A WM, parcurgând următorii paşi: 

- Definirea modelului multidimensional logic. Trebuie definite dimensiunile, 
nivelele, ierarhiile, cuburile şi măsurile. In figura 13.16 se vizualizează nivelele 
ierarhice ale dimensiunii Clienti, iar în figura 13.17 ierarhia din dimensiunea 
Clienti. 

Maparea modelului multidimensional logic la sursele de date. Sursele de date pot 
fi tabele (tabele de fapte si tabele de dimensiuni sub formă de schemă stea) sau 
tabele virtuale. De exemplu, în figura 13.18 este prezentată maparea nivelelor 
ierarhice din dimensiunea Client la atributele corespunzătoare ale tabelei Clienti. 
/ncárcarea datelor. După ce modelul multidimensional a fost definit şi mapat, 
datele pot fi încărcate si agregate în spaţiul analitic . 

Analiza datelor. Datele din spaţiul analitic pot fi vizualizate utilizând AWM 
(figura 13.19) şi analizate utilizând instrumentele Oracle Discoverer Plus OLAP, 
Oracle BI Spreadsheet Add-Inn sau aplicaţii construite cu Oracle BI Beans. De 
exemplu, instrumentul Oracle BI Spreadsheet Add-Inn care apare ca submeniu în 
Excel (figura 13.20), le oferă utilizatorilor posibilitatea de a utiliza interfaţa de tip. 
foaie de calcul tabelar pentru cereri ad-hoc, în timp ce gestiunea şi securitatea 
datelor este realizată de SGBD Oracle. După conectarea la sursa de date OLAP 
(spaţiul analitic) se deschide automat opțiunea Oracle OLAP Query Wizard care 
permite utilizatorilor să creeze cereri analitice (cereri OLAP). Se pot selecta 
măsurile, dimensiunile incluse în cerere şi membrii din fiecare dimensiune. De 
asemenea, se pot defini măsuri derivate. De exemplu, în figura 13.21 sunt afişăţi 
membrii selectaţi din dimensiunea Produse, in figura 13.22 o cererea OLAP foarte 
simplă în mediul Excel, iar în figura 13.23 modul de definire a unei măsuri 
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derivate şi anume modificarea procentuală a volumului vălizărilor curente fe de 
volumul vânzărilor dintr-o perioada anterioară de timp. 


fede ai 
Fig. 13.16. Definirea nivelelor ierarhice dintr-o dimensiune 
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Fig. 13.20. Instrumentul Oracle BI Spreadsheet Add-In 
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Fig. 13.23. Definirea unei măsuri derivate 


13.5. Arhitectura sistemelor OLAP. 


Sistemele OLAP permit analiştilor şi managerilor să îmbunătățească performanțele 
unei firme, printr-un acces interactiv rapid la o mare varietate de viziuni de date organizate, 
pentru a reflecta aspectul multidimensional al datelor dintr-o întreprindere. Cele mai multe 
aplicaţii OLAP sunt foarte împrăștiate. 

În general mai puțin de o celulă dintr-o mie de celule are date, Deoarece aplicaţiile 
OLAP sunt de fapt sisteme suport de decizie interactive, este important ca ele să rămână 
rapide, chiar dacă baza de date este mare şi împrăștiată, Se urmăreşte să se consume mai puţin 
spaţiu fizic pentru stocarea informaţiilor lipsă sau a indecșilor. Există multe soluţii, fiecare cu 
avantaje şi dezavantaje. 

Factorii care determină alegerea unei soluţii sunt : 

- Volumul de date curente stocat; 

Z Gradul de împrăştiere a datelor. Dacă datele sunt foarte împrăștiate, poate fi 
necesară o indexare mai complexă şi compresia datelor, care vor face instrumentul 
mai lent; 

m Frecvența de actualizare a datelor şi modul cum se face actualizarea; 

- Numărul de utilizatori; 

2 “Tipul arhitecturii client/server (unde are loc procesarea multidimensională); 

- Frecvența de modificare a dimensiunilor bazei de date, etc. 

Ținând cont de aceşti factori, proiectanți de instrumente OLAP selectează tehnicile pe 

care le vor utiliza pentru a stoca şi gestiona datele multidimensionale, pentru aceste aplicaţii. 
Astfel, nici un instrument nu este optim pentru orice aplicație OLAP. Toate instrumentele 
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folosesc o combinaţie de tehnici. Prima decizie ce trebuie luată este de a stabili unde 
stocate datele din model, când sunt procesate şi accesate. is 

În ultimii ani, un numár mare de instrumente OLAP permit stocarea datelor atăt in - 
baze de date relaționale cât şi multidimensionale. Astfel, modul de stocare a datelor a devenit 
un criteriu de clasificare a sistemelor OLAP si anume în: sisteme ROLAP, sisteme MOLAP şi 
sisteme HOLAP. 


13.5.1. Sisteme ROLAP 


În ultimii ani, un număr mare de instrumente OLAP permit stocarea datelor 
multidimensionale în baze de date relafionale (depozite de date). Chiar dacă o aplicaţie OLAP 
stochează toate datele sale într-o bază de date relaţională, totuşi ea va lucra separat, pe o copie 
separată a datelor (depozite de date/centre de date), nu pe baza de date tranzacţională, 
utilizând schema stea sau fulg de zăpadă. Problema este de a oferi acces rapid și flexibilitate 
în manipularea multidimensională. Dacă sunt multe variabile, există posibilitatea de a nu le 
putea stoca pe toate într-o singură tabelă de fapte (gradul de împrăştiere poate diferi mult între 
grupurile de variabile). Datele pot fi încărcate din multiple surse, astfel actualizările unei 
singure tabela de fapte foarte mare sunt ineficiente. De aceea, în aplicaţiile complexe, tabela 
de fapte este partiţionată in grupuri de variabile după gradul de împrăştiere, stabilindu-se, de 
asemenea, dimensiunile c şi sursele de date. În aplicaţiile OLAP complexe pot 
exista 10..20 de tabele de fapte. Pentru o bună performanţă la interogare, unele agregări 
trebuie antecalculate si stocate în tabele de agregate, În aplicaţiile complexe pot exista mii de 
tabele de agregate. 

Eficienţa la interogare este factorul dominat asupra performanţei globale si a 
scalabilităţii sistemului ROLAP. Strategiile de optimizare sunt factorii principali în 
diferenţierea sistemelor ROLAP existente. Întrucât optimizatorul de cereri al SGBDR ar putea 
să nu fie capabil să aleagă planul de execuţie optim pentru cereri, unele instrumente (de 
exemplu DSS Server/Microstrategy) împart cererea complexă în mai multe subcereri, care 
sunt executate secvențial (SQL în mai mulți paşi). 


Un sistem OLAP va utiliza o bază de date relaţională atunci când: 

- Volumul de date este prea mare pentru a fi duplicat. Datele atomice nu sunt 
copiate în baza de date multidimensională, ci sunt stocate în baze de date 
relafionale sursă (depozite de date/centre de date) si citite atunci când este nevoie; 

- Datele sursă se modifică frecvent şi este mai bine de a citi în timp real decât din 


copii; 
* Se doreşte integrarea cu alte sisteme informatice relafionale existente; 
- Firma are o politică de neduplicare a datelor, pentru securitate sau alte motive, 


chiar dacă aceasta conduce la aplicaţii mai puțin eficiente; 


Volatilitatea descrie gradul la care datele şi structurile de date se modifică în timp. — 
Datele cu un nivel de volatilitate scăzut rămân relativ constante. De exemplu, datele despre 
timp au un nivel scăzut de volatilitate (zilele sunt grupate întotdeauna în luni și lunile sunt =. 


i 


Atât sistemele ROLAP cât şi cele MOLAP sunt optime pentru aplicaţii cu volatilitate scăzută 


Baze de date multidimensionale 


datelor. Pentru aplicaţiile cu volatilitate ridicată a datelor, numai sistemele ROLAP sunt 
optime. 


13.52. Sisteme MOLAP 


stocarea şi gestionarea datelor 
unanim acceptată. Stocarea fizică a datelor multidimensionale, precum si fenomenul de 


| merid e e tată ri importante, deja rezolvate în SGBDR: 
dar care sunt nerezolvate sau numai parțial rezolvate în SGBDMD cum ar fi: restaurarea 

s dme ot ere e, exempla Arbor Essbase ) permit acces muliiutilizator 
pocta Mes rudei scriere. SGBDMD blochează întreaga bază de date 
hd Ade popi ce pim cart e ROLAP gi sistemele 
MOLAP. 


[Criterii ROLAP/Baze de date relajionale 
Spaţiul de disc ocupat posibil zero, dacă sunt folosite 


baze de date existente 


extrem de mare (Gb-Tb). 
excelentă în principiu, dar poate fi 
limitată dacă este folosită o 

schemă complexă 


(integrare cu alte sisteme 
existente) 


13.5.3. Sisteme hibride (HOLAP) 


Un sistem OLAP hibrid (HOLAP) este un sistem care utilizează pentru stocarea 
datelor atât baze de date relajionale cât și baze de date multidimensionale. Sunt diferite 
arhitecturi pentru un sistem hibrid OLAP: 

-~ integrarea sistemelor MOLAP si ROLAP printr-o interfaţă comună. Clientul OLAP 
poate fi luat în considerare într-o astfel de soluție, întrucât oferă o interfaţă comună 
pentru SGBDMD si SGBDR. 

- integrarea mutuală a sistemelor ROLAP şi MOLAP. Aceasta arhitectură poate fi găsită 
la Arbor Essbase, Oracle. 

- extensii la SGBDR sau SGBDOR prin utilizarea tehnologici darablade (de exemplu 
Informix cu opţiunea Metacube). Totuși acesta nu este un sistem OLAP hibrid 
(Metacube este un ROLAP, deci nu este încă implicat un SGBDMD). 
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| Evoluția tot mai rapidă a performanțelor sistemului de calcul a determinat 
| diversificarea tipurilor de date asociate atributelor unei entităţi stocate într-o bază de date. 
^ Astfel, multe aplicaţii utilizează date spaţiale; dintre acestea cele mai sugestive sunt cele din 
` clasele: 


* sistemelor informatice geografice (GIS); 

- proiectării asistate de calculator; 

- multimedia; ` 2 

~ toate având în comun faptul că stochează şi manipulează date spatiale. 


14.1. Tipuri de date spaţiale 


spaţială este un termen utilizat pentru a descrie datele care aparțin spaţiul 
ocupat per unei baze de date. In sens larg, datele spaţiale pot fi: puncte, linii. 
poligoane, suprafețe, volume (date având mai multe dimensiuni). ? m 
Punctul este caracterizat prin locaţia sa, nu ocupă spaţiu $i nu are asociată o arie sa 
un volum. Intr-o bază de date punctul se stochează printr-o măsură directă a lui sau printr-o 
măsură indirectă (transformare). Data de tip raster este un exemplu de folosire a nul 
directe a unui punct şi include harta de pixeli (imaginea bitmap). De exemplu, o imagin: 
preluată din satelit realizează o corespondenţă directă între un pixel de imagine si suprafața 
pollere E AD ic t de început şi cel de sfirşii) 
Und ie aciei krmni Si fe Melee priivereție dua Un obiect at ec 
descris, de obicei, printr-o colecţie de segmente ca de exemplu cursul unui riu sau un Rd 
O dată spaţială de tip regiune se caracterizează printr-o locaţie si un contur. aa, 
pe calami pinten a epoca Mota în mei Gene i E qim 
regiunii). In spaţiul bidimensional, conturul se vizualizează ca o linie iar | 
tridimensional ca o suprafață. Data de tip regiune stocată into bază de date este 
aproximare geometrică a unui obiect spaţial (de exemplu, judeţele unei țări, oma e) W 
Datele spațiale sunt frecvent puse în corelaţie cu atribute convenji e e 
nonspațiale). De exemplu, un judeţ se descrie spațial printr-un poligon (regiune) dar 5 
nonspafial prin nume, suprafaţă, număr de localități, populaţie ete. Atributele spațiale ai 
cele nespatiale apar si la nivelul conceptual. Astfel, valoarea unui atribut spațial este ee 
tuturor atributelor nespafiale dintr-un tuplu. Tuplurile unei tabele care confine un atri 
t spaţial pot fi vizualizate atit geometric (spaţial) cit şi în mod clasic, relafional (tabelar). W 
Pentru exemplificare, să presupunem că tabela judeţe stochează județele Toota 
descrise printr-un atribut spaţial de tip poligon (suprafaţă) si prin atribute nonspaţiale: 
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simbolul județului, numele si reşedinţa lui. In fi izualizează 
l județului, i. In figura 14.1 se vizual 
geometrică în timp ce, în figura 14.2, aceeași tabelă se vizualizeaza tabelar. 


esee 


tuplurile în foy 


seti 
CORE 


E 
sil 


BG 


și 


" 


ag 
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O problemă importantă a sistemului de gestiune a bazelor de date 


| ectuarea legăturii ire datele spaţiale ce sunt stocate în structuri de date specifice Const 


nespaţiale. 
Două legături sunt menţionate între aceste tipuri de date care caracterizează un anumit 
| obiect: legături înainte şi înapoi. Acestea definesc termenul de relaţie spaţială. 

Legătura înainte (figura 14.38) este utilizată la accesarea informaţiilor Spațiale ale 
nii obiect, pornind de la informațiile lui nespafiale. 

Legătura înapoi (figura 14.3b) foloseşte la regăsirea informaţiei nespafiale a unui 
obiect pornind de la informaţia lui spațială. 

Deoarece structurile de date spaţiale conţin toate informaţiile necesare pentru a 
identifica un obiect, legătura înainte poate folosi o valoare reprezentativă a unui obiect, astfel 
ca el să fie selectat în mod unic. 

De exemplu, pentru regiunile care nu se suprapun, un element de legătură înainte îl 
poate constitui un punct din respectiva regiune. Informaţiile nespaţiale aferente unui obiect se 

în mod normal într-un tuplu al relaţiei respective. Legătura înapoi poate fi realizată 
prin intermediul identificatorului tuplului respectiv. 

Menţionind aceste legături între párjile spaţiale si nespaţiale ale unui set de obiecte, se 
facilitează buna desfăşurare a procesului de interogare. 

Modelul orientat obiect poate fi de asemenea utilizat ca fundament pentru bazele de 
date spaţiale. Această metodologie permite o mai bună structurare a informaţiilor, prin 
introducerea conceptelor de clasă şi moştenire. Încapsularea datelor şi supraîncărearea 
funcţiilor facilitează manipularea datelor şi fac ca reprezentarea fizică şi logică a datelor să fie 


independente, una în raport cu cealaltă. In cazul bazelor de date spaţiale, concepte precum: 
clasa, moştenire, încapsulare, tip şi metodă sunt uşor de utilizat. Diferitele tipuri spaţiale de 
date pot fi implementate ca nişte clase cu posibilităţi de a fi moştenite, construind subclase. 


Atribute nespajiale Structuri de date spaţiale 


(a) 
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[Date nespafiale pentru Regiunea 4 


[Date nespafiale pentru Regiunea 5 


(b) 
Fig. 14.3 Tipuri de legături: înainte (a) si înapoi (b) 


Astfel, datele spatiale pot fi modelate la două niveluri: hartă şi geometric. O bază de 
date spaţială confine un set de hărţi, unde o hartă este o relație care are cel puţin un atribut 
spatial. Operaţiile cu o hartă sunt implementate ca metode ale obiectelor ce aparțin hărții. 
Nivelul geometric corespunde atributelor spaţiale care sunt reprezentate prin tipuri de date 
geometrice, ca de exemplu: puncte, linii, poligoane etc. 


14.2. Structuri de date pentru reprezentarea şi 
indexarea datelor spatiale 


După cum a fost prezentat în paragraful anterior, datele spaţiale sunt stocate in 
structuri de date spaţiale. Dintre acestea, un loc important îl ocupă cele ierarhice care sunt 
bazate pe principiul descompunerii recursive. Avantajele acestor tipuri de structuri rezultă din 
faptul că sunt compacte, depind de natura datelor și permit realizarea operaţiilor de interogare 
in mod eficient. O astfel de structură de date este quadtree si are la bază principiul 
descompunerii recursive, similar metodei divide-and-conquer. Ea se poate utiliza la descrierea 
mai multor elemente aparjinind clasei datelor spaţiale ca de exemplu: puncte, linii, poligoane 
ete. 

O dată spaţială ce exprimă o regiune poate fi reprezentată fie prin interiorul ei, fie prin 
conturul ei. Se presupune, în descrierea procesului de construire a arborelui, plecînd de la o 
imagine, că o regiune este reprezentată de interiorul ei (figura 14.4). 

Structura quadtree se bazează pe subdivizarea succesivă a unei imagini în patru 
cadrane de mărimi egale. Dacă un cadran nu confine numai valoarea 1 sau numai valoarea 0. 
el va fi din nou subdivizat în patru cadrane si aga mai departe pînă sunt obținute cadrane ce au 
fie valoarea 1 fie 0. Valorile 1 respectiv 0 semnifică faptul că zona aparține sau nu regiunii 
respective. Pentru exemplificare se va considera imaginea din figura 14.4a şi reprezintarea ei 
binară (bitmap) în figura 14.4b. Prin împărţirea succesivă în cadrane, figura 14.5a se observă 
că zonele astfel obținute (cadranele) fie aparțin regiunii fie nu. De exemplu, dacă regiunea 


402 


LA A 


este omogenă din punct de vedere a culorii atunci cadranele care acoperă regiunea trebuie să 
aibă aceeaşi culore. 


DrmmTereroro] 
(a) imagine (b) reprezentarea binară 
Fig. 14.4. Reprezentarea binară a unei imagini 
1 IV 
Lu In 
Descompunerea unei imagini în cadrane 
Niveluri 


v 


d 


Quadtree 
Fig. 14.5. Descompunerea imaginii 


Cadranele obținute în urma procesului de divizare a spațiului se pot reprezenta prin 
intermediul unui arbore numit quadtree. Structura quadíree este în esenţă un arbore oarecare 
ce confine noduri avînd semnificaţiile: 
- - rădăcina corespunde imaginii în ansamblu; , 
- nodurile frunză corespund acelor blocuri pentru care nu mai sunt necesare 

subdiviz&ri; blocurile fie aparțin regiunii (1) fie sunt în afara ei (0); 
- celelalte noduri reprezintă cite un cadran al regiunii care a necesitat o subdivizare. 
Pentru orice nod ce nu este frunză, fiii lui corespund cadranelor în ordinea NE (1), SE 


(7), SV (IID, NV (IV). 
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Structura quadtree poate fi diferită în funcţie de: 
- Tipul de dată pe care o reprezintă si care poate fi: punctul, linia, curba, suprafaţa și 


regiunea. 

- Principiul care stă la baza procesului de descompunere care se poste face în prj 

egale la fiecare nivel (descompunere regulată) sau în m päri de mărimi diferite în 
funcţie de data iniţială; 

- Rezoluția descompunerii care poate fi variabilă 

Această structură poale fi de asemenea utilizată la reprezentarea imaginilor în trei sau 
mai multe dimensiuni. Varianta cu trei dimensiuni se numeşte octree. 

Modelul de construire a acestui arbore presupune ca imaginea să fie încadrată într-un 
cub care va fi recursiv subdivizat în 8 cuburi egale şi așa mai departe pină cînd sunt obținute 
regiuni uniforme din punct de vedere a culorii ori se ajunge la un anumit nivel predefinit de 
descompuneri. 

Dezvoltarea unei structuri ierarhice este avantajoasă deoarece se poate folosi la 
procesele de interogare a datelor spaţiale dar şi pentru că se economiseşte spațiul de memorie 
necesar reprezentării unor astfel de date. 

originală a structurii quadtree a fost aceea de arbore care utiliza 
pointeri. In acest fel, spațiul de memorie consumat este destul de mare, de aceea s-au propus, 
pentru a îmbunătăţi acestă variantă, două modalităţi. 

Prima tratează imaginea ca pe o colecţie de noduri frunză, unde fiecare nod este 
reprezentat printr-o pereche de numere. Există un număr în baza 4, numit codul locației, care 
corespunde secvenței directionale ce localizează frunza şi stabileşte astfel calea de la rădăcină 
şi un număr ce indică adîncimea la care nodul frunză este regăsit. x 

A doua modalitate reprezintă imaginea în forma unei traversări a structurii quadtree. 
Ea este foarte compactă dar nu este uşor de folosit cînd se doreşte accesul aleator la un anumit 
nod. 


Reprezentarea punctelor se face în funcţie de operaţiile care urmează să se execute cu 
aceste date. Dintre multiplele moduri de reprezentare a punctelor, adecvată este structura de 
date PR quadtree (P pentru puncte şi R pentru regiuni), deci o adaptare a structurii quadtree la 
tipuri bine precizate de date spaţiale. Această structură se bazează pe o descompunere regulată 
care urmăreşte asocierea unui punct cu un cadran. Procesul de construire este similar cu cel al 
structurii quadtree, diferenţa este că nodurile frunză fie nu conţin nimic, fie conțin puncte prin 
valorile coordonatelor lor. In figura 14.6 se poate observa corespondența dintre puncte şi 
cadrane care stă la baza construirii 

Dezavantajul metodei constă în faptul că, dacă punctele sunt foarte apropiate, atunci 
nivelul maxim de descompunere poate fi foarte mare. Avantajul este că structura devine 
atractivă în cazul în care prelucrarea datelor spaţiale implică operaţii de căutare. Un exemplu 
tipic de folosire a arborelui 1! constituie determinarea oraşelor din nord-estul țării. Oraşele vor 
fi căutate în regiunile care compun cadranul NE al imaginii (Suceava și lagi), lucru uşor de 
realizat avînd în vedere modul de construire a structurii Ă 

In concluzie, se poate spune că structura guadiree este dinamică în sensul că poate fi 
adaptată cu ușurință la mai multe tipuri de date spaţiale. 

Pentru manipularea datelor spaţiale este nevoie ca acestea să fie reprezentate În 
diferite forme. O modalitate constă în a utiliza structuri de date bazate pe ocuparea spaţială a 
datelor. Aceast metodă presupune descompunerea spaţiului în regiuni numite partiţii. De 
aceca, metoda este cunoscută sub numele de metoda partiționării. Partiţionarea. datelor 
spațiale se bazează pe conceptul minimizării ariei ocupate de partiție. In acest caz, obiectele — 
spaţiale sunt grupate în ierarhii şi apoi ele sunt stocate în alte structuri de date. Structurile de — 
indexare a datelor spaţiale multidimensionale au la bază două abordări: 3 


k 4 
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- prima se bazează pe observaţia că data spaţială ocupă un subspafiu a spațiului 
ultidimensional; F 
Tea de-a doua se bazează pe faptul cà data fiind multidimensională, un număr mic 
de dimensiuni stochează majoritatea informației. 
(0,100) (100,100) 


Fig. 14.6. Descompunerea în cadrane a imaginii 
pentru construirea structurii PR quadtree 


Structura arborescentă R (Rectangle tree), face parte din prima categorie şi este 
similară ca reprezentare şi mod de exploatare cu arborele B. Ea are mai multe TR 
proiectate în scopul organizării unei colecții de date spațiale prin reprezentarea lor in 
dreptunghiuri n dimensionale. Fiecare nod în arbore corespunde celui mai mic dreptunghi n 
dimensional care include fii lui. Nodurile frunză conțin pointeri ce referă datele spaţiale din 
baza de date. Obiectele sunt reprezentate prin cele mai mici dreptunghiuri care le conţin. 

Arborele R este aplicat unei tabele cu tupluri reprezentind date spatiale, fiecare tuplu 
avind un unic identificator care poate fi utilizat la regăsirea lui. 

Arborele R conține noduri frunză de forma (7, i id), 


I - wn dreptunghi n dimensional ce reprezintă o cutie ce mărginește obiectul 
iid - identificatorul tuplului şi se referă la înregistrarea din tabelă ce confine 
obiectul mărginit de Z. 
s numărul de dimensiuni; 

Jj, Tun interval închis [a, 5] ce precizează extinderea obiectului pe dimensiunea i. 
Astfel, J, poate avea una sau ambele limite egale cu co indicind faptul că obiectul se extinde la 
a. 


I7 (Hoy hi. oa), 


Nodurile ce nu sunt frunze in arborele R au următoarea formă: ( /, pfiu), 
unde: 

- adresa nodului mai mic în arborele R; "m 1 

ny - un dreptunghi ce acoperă toate dreptunghiurile din intrarea nodurilor mai 
mici. 

Se presupune că un nod conține maxim M elemente iar mS M/2 este un parametru ce 
specifică numărul minim de elemente dintr-un nod. Un arbore are proprietatea că un nod 
Webuie să conţină între m şi M elemente dacă el nu este rădăcină. Ca exemplu, se consideră 
colecţia de segmente dată în figura 14.7. 


Fig. 14.7. Colecţie de segmente 


În figura 14.8 se prezintă arborele R asociat colecţiei de segmente din figura 14.7, 
nodurile având capacitatea de maxim două elemente. Se poate observa în figura 14.8a modul 
de partifionare a spațiului în vederea încadrării obiectelor spaţiale şi relația de incluziune 
dintre partiţii, iar în figura 14.8b este descrisă aceeaşi relație de partifionare şi includere prin 
intermediul structurii arborescente R. 

Din figura 14.8 reiese că, din partifionarea spaţiului nu rezultă regiuni disjuncte. Zona 
de intersecţie reprezintă procentul din volum care este acoperit de mai mult de un dreptunghi. 
Dacă un nod al unui arbore R conține n dreptunghiuri (Ry,....Ra). zona de intersecție poate fi 


definită formal ca în relaţia 14.1. 
| U «n 2) 
ati nin) 


Zona de intersectie = 


unde, || A|| - indică volumul acoperit de A. 


Un alt concept legat de intersecţia suprafețelor este greutatea intersecţiei care 
reprezintă procentul de obiecte care aparţin porțiunii de intersecție din spaţiu. 


lere U ans) 
s) 


pipe U 


iei n] 


Greutatea intersectiei = (14.2) 


unde: 
- |A] , indică numărul de obiecte conținute în A; 
- p. obiect spaţial. 


O dată spaţială se asociază cu un singur dreptunghi, de exemplu, în figura 14.8, 
segmentul í este asociat dreptunghiului RS cu toate că şi partifiile RI, R2 şi R4 partajează o 
suprafaţă din RS. In aceste condiții dacă se doreşte să se determine care obiect este asociat cu 
un punct particular vor fi necesare mai multe căutări în baza de date datorită faptului că acel 
punct poate fi conţinut în mai multe partiţii. K 

Algoritmii de căutare, inserare şi ştergere sunt construiți folosind aceleaşi principii 
utilizate la implementarea structurii arborescente B°. Informaţiile ce se manipulează se referă 
la marcarea dreptunghiului 7, la cheia tuplului, respectiv la pointerul la subarborele 
corespunzător. 


Fig. 14.8, Arborele R 


O problemă dificilă ținând cont de particularitatea datelor spațiale este aceea 4 
divizärii nodului. Fiind dată 0 paginá ce conține M elemente este necesar să se dividă colecția 
de M+1 elemente între două noduri. ó 

Divizarea unui nod S*(ri,..,r.) in două subnoduri Sı” {ri 
(Si«Z si S42) este definită ca: 

Diviz(S)-( (S152) / S-SijuS;^Sin2-2 ). 

In urma procesului de divizare a nodului pot apare cazurile: — 

- zonă de intersecție minimală, dacă || (S1) © r(S2) || este minimă; 

- zonă de intersecţie inexistentă, dacă | (S1) ^ r(S2) || = 0; 

- echilibru dacă -£ < [Si] - [S2 se. s — 

Deoarece decizia de a vizita un nod depinde dacă dreptunghiul aferent lui uua ra 
căutată, rezultă că aria totală de acoperire a celor două dreptunghiuri după divizare trebuie 
fie minimă. : y 

Comparând figurile 14.9 a şi b se realizează o mai bună 

iteriul it în figura 14.9a. > 

p jp peru litate sunt prezentaţi mai mulți algoritmi ce realizează acest lucru 

| eril de divizare Quadratic este recunoscut datorită eficienței sale și distribuie 
un set de M-1 elemente între două noduri. 


a} si Sz tere 


încadrare având în vedere 
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Fig. 14.9 Incadrarea zonelor de acoperire 

În primul pas se vor alege două elemente din cele M+1 ce vor fi puse, câte unul, in 
cele două noduri. In acest sens, se va calcula ineficienfa grupării pentru toate elementele, 
Astfel, pentru fiecare pereche r, r, se compune un dreptunghi R incluzind ariile r,, r, Se 
calculează: 
d= aria (R) - aria (rj) - aria(r;) şi se alege în final perechea pentru care rezultă cea mai mare 
valoare d. 

În al doilea pas se controlează dacă toate elementele au fost distribuite la cele două 
noduri. In caz afirmativ algoritmul se opreşte. Altfel, dacă un nod are puţine elemente, restul 
rămase nedistribuite vor fi asignate la el pentru a avea numărul minim m şi in acest caz 
algoritmul se oprește. 

În al treilea pas se selectează următorul element pentru a fi asignat la unul dintre 
noduri. Pentru fiecare element rămas 7 se calculează d, aria mărită necesară pentru includerea 
dreptunghiurilor elementelor din primul nod plus zona dată prin r. Se calculează de, similar 
pentru elementele nodului al doilea. Se găseşte astfel elementul cu cea mai mare preferință 
pentru un grup. Se alege acela pentru care diferența între d, şi d» este maximă. Acesta se va 
adăuga la grupul al cărui dreptunghi acoperitor va trebui să fie cel mai puţin mărit pentru a 
cuprinde elementul. Legătura se rezolvă şi prin adăugarea elementelor la nodul cu o arie mai 
mică de cuprindere sau la unul cu mai puține intrări. Apoi se continuă cu pasul doi. 

Acest algoritm nu garantează găsirea celui mai mic dreptunghi posibil de încadrare dar 
performanțele lui sunt destul de bune luind în considerare necesarul de timp de prelucrare 
pentru obținerea rezultatului. 

Paniţionarea spaţiului în partijii disjuncte a dus la crearea unei structuri derivate din 
arborele R şi anume A”. Deoarece regiunile sunt disjuncte, înseamnă că pot fi obiecte care nu 
se încadrează doar într-o singură partiție. De aceea, ele se vor descompune in subobiecte, 
fiecare aparţinând unor regiuni diferite. Devine, astfel, important să se determine partifiile 
care conţin o anumită dată spaţială. 

În figura 14.10 se prezintă un arbore tip R^ pentru aceeaşi colecție de segmente 
(prezentată în figura 14.7). Se observă că fiecare obiect este asociat cu toate partifiile care-l 
intersectează deci, pot fi mai multe căi de la rădăcină până la unul si acelaşi obiect. De 
exemplu, în figura 14.10 segmentele c şi f apar în două noduri diferite, în timp ce segmentul f 
apare în trei noduri. 1 

În literatura de specialitate s-a demonstrat că structurile de indexare bazate pe arbori R 


mare de dimensiuni este arborele X (eXtended node tree). Structura arborelui X este 
prezentată in figura 14.11. j 
Se observă că el conține trei tipuri de noduri: E 

- noduri de date care sunt la nivelul frunzelor si fac legătura cu datele spațiale care, 

se indexează; 


i nodurilor interne dintr-un arbore R; şi 


noduri directoare normale ce au rol în a dirija căutarea prin arbore şi sunt similare 
supernoduri care sunt în fapt noduri directoare de mărime variabilă. 


Fig. 14.10. Arborele R 

este să evite divizarea nodurilor directoare, 
cà el conține noduri de dimensiuni mai 
mari oar dacă este necesar. Superodurile sunt create în timpul inserării când capacitatea 
unui nod trebuie depăşită si nu se poate evita acest lucru prin alte procedee. 


arbore depinde de viteza de prelucrare secvenţială a 


arborele X are o organizare complet ierarhică a nodurilor directoare şi 


jul rădăcină corespunde nivelului celui 
arbore R. Performanţele unui astfel de 


14.3. Exploatarea datelor spaţiale 


spaţială, dacă operația efectuată implică un atribut spațial atunci ea 
sa mun ar oo epi Astfel, dacă Se elizază reuniunea a două județe atunci operația 


de reuniune este considerată ca fiind spaţială. a 
bazează pe utilizarea operatorilor. De aceea, trebuie 
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datelor dintr-o bază de date se 
menţionat tipul de bază de date spaţială 


utilizată care poate fi relationalá sau orientată obiect jar în strînsă legătură cu tipul bazei de 
date se va preciza si sistemul de gestiune folosit pentru exploatarea ei. 


Cy - nod de date 


Fig. 14.11. Structura unui arbore X 


Unul dintre cele mai cunoscute sisteme de gestiune a bazelor de date spaţiale este 
ArcGIS creat de ESRI. Acest pachet software a fost dezvoltat mai mult ca o interfaţă grafică 
pentru achiziţia si prelucrarea datelor spatiale dintr-o bază de date relaţională. ArcGIS nu este 
propriu-zis un sistem de gestiune a bazelor de date pentru că el nu are un format propriu de 
organizare a bazei de date ci utilizează formatele altor sisteme de gestiune a bazelor de date 
relagionale cunoscute, cum ar fi: Access, ORACLE, Microsoft SQL Server, Dynamic Server 
Informix. El manipulează si date spaţiale stocate independent dc o bază de date de exemplu, 
în format shp, memorate într-un fişier de sine stătător, 

În denumirea software-lui apare şi GIS ceea ce sugerează că este folosit pentru a 
implementa sisteme informatice geografice, adică în principal lucru cu hărţi digitale. Aceste 
sisteme au o largă aplicabilitate, principalele domenii de utilizare sunt: 

- pentru gestiunea elementelor ce țin de mediul înconjurător (zone protejate, resurse de 
apă, culturi, managementul deşeurilor, dispersia noxelor în teritoriu etc.); 

- pentru gestiunea rețelelor de: transport, conducte, cabluri electrice etc; 

- pentru rezolvarea problemelor de amplasare de obiective cum ar fi: staţii de emisie / 
recepţie, gropi de gunoi, staţii de epurare etc; 

- pentru prezentarea informaţiilor meteorologice; 

~ pentru gestiunea cadastrală a teritoriului. 


Într-o bază de date spaţială, datele spaţiale se memorează astfel încât o tabelă să 
conţină o caracteristică spaţială de același tip. De exemplu, tabela judere stochează judeţele 
României iar caracteristica spaţială este de tip poligon. Din punct de vedere vizual, în ArcGIS. 
datele spaţiale sunt prezentate prin straturi tematice (layers). In figura 14.12 se prezintă harta 
României prin intermediul a două staturi tematice (drumuri şi județe). 

Judejele au fost etichetate cu simbolurile utilizate la numerele de înmatriculare 2 
autovehiculelor. 
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Fig. 14.12. Harta României reprezentată prin dată str 


Operația de selecție a datelor spaţiale se poate realiza ia dous =o 


select * from drumuri where ([TIP2]= 'E' AND [NUME2] 585) O2. 
AND [NUME3] = '£85% 


După execuția acestei comenzi, pe hartă, drumul european E55 va È marcat în mod 
distinct după cum se poate observa în figura 14.13. 


ze judeje rece 


- condiția implică cel puțin un atribut spaţial; pezcz 2 deze: t 
Zilizină forma 


drumul european E85 se va defini următoarea interogare. 

din figura 14.14. : 

Se observă că se selectează atribute spațiale dia relația jicizie ce intersectează 

Caracteristicile selectate din relația spațială drumuri. In urma execciei rez-:à hara ca în 

figura 14.15, adică se observă că judeţele prin care trece cromul eu-ozezn ESS au fost şi ele 
lectate. 


g 


4n 
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Fig. 14.15. Selecţie prin localizarea datelor spaţiale 


ppoerroonprpo 


- Fig, 14.14. Formă de interogare spaţială 


Rezultatul selecţiei se poate concretiza într-o tabelă distinctă sau se poate construi un 

AeA M el d A dii s 
einge pe E bes px i peccatur sino tento Jur EDO 
z operației lecție spaţială acele judeţe prin care trece 


Fig. 14.16. Strat tematic format din selecţie 


O altă operație relațională cu relevanță pentru datele spaţiale este cea de reuniune. Prin 

această operație se urmăreşte obținerea unui nou strat tematic constituit din uniunea mai 

" multor date spaţiale. De exemplu, dacă se doreşte obţinerea unei date spaţiale corespunzătoare 
regiunii Nord-Est, ea se poate obține prin reuniunea judeţelor care formează regiunea. 
Produsul software contine o componentă specializată, numită AcrToolbox pentru efectuarea 

de geoprocesări (procesarea datelor spaţiale). Fiind definit în sistem deschis, el oferă 
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utilizatorilor posibilitatea de a-şi defini propriile instrumente de lucru, acestea fiind construite 
prin crearea de noi modele şi stocate în componenta crToolbox. Modelul ajută utilizatorul 
să-şi definească o operaţie spaţială complexă ca o succesiune de operaţii elementare, eventual 
parametrizabilá ca să poată fi folosită în diferite contexte de lucru. 
Operația de formare a regiunii prin reuniunea judeţelor ce o formează necesită 
efectuarea mai multor paşi: 
- selectarea judeţelor care formează regiunea; 
- reuniunea lor; 
- agregarea poligoanelor obținute prin reuniune pentru a rezulta o singură 
caracteristică spaţială. 
Parametrizarea modelului se face în scopul de a oferi mai multă generalitate operaţiei 
fMi NM Da ROS SE SUI a 
caracteristica spaţială din care se vor selecta elementele care vor intra în operația 
de reuniune; 
-~ expresia de selecţie care va fi asociată clauzei where a frazei select. 


ie mere camee reuniune 


Pentru definirea modelului de utilizator a fost adăugat un nou Toolbox cu denumirea 
Regiune, iar în cadrul lui s-a creat un model denumit constr_regiune, după cum se poale 
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| cinema în fara 1447. Modelele se definesc şi se execută într-un context de lucru 
| (Workspace), care în exemplul nostru este format din harta României descrisă prin judeţe ca 

| în figura 14.18. 

H Definirea unui model se face vizual prin construirea unei diagrame de flux care indică 

| succesiunea operaţiilor elementare care trebuie realizate pentru a se ajunge la rezultatul final. 
Obţinerea regiunii presupune definirea modelului ca în figura 14.19. 


Tig. 14.19 Descrierea modelului pentru Obținerea unei regiuni 


In cadrul modelului, o operaţie elementară se figurează ca în figura 14.20, 


(ns ae) 


Fig. 14.20 Structura de bază a modelului 


Din figura 14.19 se observă că operația de selecție primeşte două intrări figurate cu 
litera P ceea ce înseamnă că ele pot fi parametrizate, adică utilizatorul poate furniza alte date 
de intrare când rulează modelul. Prin selecție sc urmăreşte ca din toate tuplurile unci tabele 
spaţiale să se păstreze doar cele care vor participa la operaţia de reuniune. Operația de selecţie 
a fost parametrizată astfel încât utilizatorul sa-şi poată alege caracteristica spaţială iar pe de 
altă parte să poată furniza condiţia de selecţie, adică expresia asociată clauzei where. 

Când se rulează modelul va apare un dialog în care utilizatorul îşi poate seta aceşti 
parametri după cum se observă în figura 14.21. 


Fig. 14.21 Dialogul pentru setarea parametrilor modelului constr regiune 


Expresia de selecție implică atributul nonspaţial simbol al tabelei județe. Astfel, s-au 
selectat acele judeţe care formează regiunea Nord_Est a României. 

Rezultatul operaţiei de selecţie se constituie ca intrare pentru operația de uniune. 
| Reuniunea judeţelor se concretizează printr-o multime de poligoane care formează regiunea 
tespectivă. Pentru obținerea regiunii ca dată spaţială de sine stătătoare se efectuează operația 
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coasta 


de agregare a judeţelor (poligoanelor) (Aggregate Polygons) care formează regiunea, rezultind 
un singur poligon. Această caracteristică spaţială se concretizează într-un nou strat tematic 
(Regiunea_rezultată) după cum se poate observa în figura 14.22. 


Fig. Vries regiune 


Prelucrarea datelor spaţiale implică formarea unor regiuni la momentul execuţiei, 
regiuni necesare pentru a delimita un anumit spaţiu. De exemplu, dacă c necesar să 
identificăm localităţile care se-află în jurul râului Olt, la maxim 2 km, atunci ar trebui să 
delimităm regiunea aflată în jurul râului la o distanţă de 2 km. Se vor utiliza următoarele 
caracteristici spațiale; concretizate în straturile tematice: localităţile României şi râurile. 

Primul pas constă în a selecta râul Olt pe hartk Acest lucru se realizează prin 
efectuarea unei selecţii implicând în condiţie un atribut nespatíal din tabela rduri si anume 
den, care stochează denumirea râurilor. Operația propriu-zisă se poate declanșa prin execuţia 
comenzii: 


SeleciLayerByAttribute râuri NEW. SELECTION " den = 'Olr' * 


ce va fi introdusă în fereastra de co numită Command Line. 

După selecţia râului Olt se poate construi regiunea din jurul lui construind un buffer. 
Operația de construire a buffer-ului se declanşează din ArcToolbox/Analysis 
TooVProximity/Buffer, setarea parametrilor se face prin dialogul din figura 14.23 

Principalii parametri au semnificaţiile: 

= Input Features - caracteristica spaţială în jurul căreia se creează buffer-ul, în 

exemplu este vorba de râuri, mai precis râul Olt anterior selectat; 

* Output Feature Class - denumirea caracteristici spaţiale de ieşire, implicit este 

ráuri Buffer, adică bufferul se va constitui într-o caracteristică spaţială de sine 
stătătoare; 


- Linear unit - este parametrul prin care se stabileşte distanța la care se va trasa — 
Cin al A tuia cu eclesie po de ti ior ici 2 


poate stabili şi unitatea de măsură a distanţei. 
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: E c 
Fig. 14.23 Dialog pentru setarea parametrilor operaţiei de creare a unui buffer 


Rezultatul operaţiei se poate observa in figura 14.24. Astfel, stratul tematic 
ráuri Buffer defineşte o suprafaţă, construită în jurului râului Olt la o distanţă de 2 km. 


Pentru obţinerea localităţilor ce se află în vecinătatea râului Olt se va efectua o 
operaţie de selecţie spaţială, mai precis se vor selecta toate localităţile care intersectează 
suprafața creată prin operaţia de buffer-izare (râuri_ Buffer), utilizând comanda: 


SelectLayerByLocation localitati INTERSECT råuri_Buffer 0 NEW. SELECTION 


Fig. 14.24. Buffer aplicat in jurul râului Olt 
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După execuția acestei comenzi se poale crea un nou strat tematic numai cu localitățile 
selectate, rezultatul operației de filtrare se poate vedea în figura 14.25. 

y Pentru dezvoltarea de aplicații, ArcGIS foloseşte limbajul Visual Basic cu ajutorul 

căruia sunt manipulate prin programare obiecte definite în ArcGIS, ca răspuns la 


evenimentele generate de utilizator. Se pot utiliza diferite elemente de interfaţă cum ar fi cele 
specializate în acest sens: bare de instrumente, meniuri, căsuțe de dialog; iar pe de altă parte, 
se pot utiliza chiar date spațiale pentru a realiza interacțiunea cu utilizatorul. 


oana — 


Fig. 14.25. Selecţia localităţilor din vecinătatea râului Olt 
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Capitolul 15 
Baze de date multimedia 


15.1. Cadrul conceptual 


Utilizarea pe scară largă a calculatoarelor a făcut posibilă trecerea de la folosirea unor 
structuri statice de prezentare a informaţiei (cărţi, reviste), la unele capabile să realizeze o 
uşoară actualizare a lor. Primele sisteme de calcul au manipulat şi prezentat informaţia într-o 
formă alfanumerică. Îmbunătăţirea tehnologiilor în direcţia dispozitivelor de memorare, a 
adaptoarelor grafice, mărimea memoriei principale cât si a celei externe precum și puterea 
procesorului a dus la apariția a noi tipuri de date cunoscute sub numele de date 


Termenul de multimedia este destul de greu de definit deoarece este interdisciplinar. 
Din punct de vedere informatic, multimedia se defineşte ca o combinaţie de: text, grafică. 
imagine, animaţie, sunet, video accesibilă utilizatorului prin intermediul sistemului de calcul. 

Sistemele informatice multimedia sunt acele sisteme informatice care gestionează 
informaţii multimedia, folosesc multimedia pentru prezentare și utilizează instrumente 
specifice pentru stocarea, manipularea şi regăsirea informaţiei multimedia. Sistemele pentru 
stocarea si regăsirea informatici multimedia au fost proiectate și dezvoltate pentru diferite 
tipuri de aplicaţii. Multe dintre modurile de gestionare si prezentare a acestor informaţii au 
fost adaptate şi utilizate în contextul acestor sisteme. 

Datele tradiţionale sunt în esenţă statice, starea lor este invariabilă în timp, afară doar 
de cazul în care există o intervenţie externă, explicită a utilizatorului sau a sistemului de 
gestiune, iar gradul lor de interactivitate cu utilizatorul este minim. Prin comparație, 
informația multimedia este dinamică și deci intrinsec activă şi reactivă. Reactivitatea se 
raportează la posibilitatea de modificare chiar a stării mediului prin intermediul unor 
evenimente externe, nu numai la o simplă variaţie a conţinutului. Un video sau o secvenţă 
muzicală poate fi întreruptă, eliminată, distribuită dintr-un punct de întrerupere ori de la 
început sau i se poate altera conţinutul. La fel, o imagine poate fi schimbată, mărită sau 
redusă. Datorită dinamicii datelor multimedia, metodele si tehnicile de prelucrare sunt mult 
extinse faţă de o bază de date clasică. Mediul este si el activ, deoarece starea lui poate evolua 
în timp în mod independent de fiecare acţiune externă. Un video odată activat, poate fi parcurs 
până la sfârşit, dacă utilizatorul sau sistemul nu intervine explicit. Mai multe medii diverse 
pot fi activate simultan şi sincronizate între ele pe parcursul derulării. Pe de altă parte 
imaginile, datele audio si video pot avea dimensiuni de multe milioane de bytes, ceea ce 
presupune găsirea unor noi soluții de prelucrare a datelor. Pentru o gestiune automată, 
informaţia multimedia este structurată pe obiecte complexe, compuse din diferite unităţi de 
informaţii elementare, conectate natural între ele. De exemplu, într-o aplicaţie salon auto 
virtual, informaţia relativă la un automobil poate fi compusă din imagini corelate cu note 
explicative dar poate fi compusă și dintr-un film scurt care ne redă modul de desfăşurare a 
diferitelor faze din procesul de producție a automobilului respectiv. 
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Utilizarea obiectelor complexe rezolvă atit problema de memorare si de gestiune, cit si 
pe cea de prezentare, prin manipularea simultană sub un model unic a mai multor unități de 
informaţii de diverse dimensiuni şi durate. Datele multimedia necesită un larg spaţiu de 
memorie pentru a putea fi stocate, Ele sunt frecvent comprimate pentru a reduce spaţiul de 
memorie necesar, algoritmii de compresie folosiţi sunt variaţi si formează nişte ped 
JPEG, MPEG, PX64 etc. Acest lucru are si dezavantaje în sensul că regăsirea unei părţi dintr. 
o imagine comprimatà este dificil de realizat ca şi derularea într-un sens sau altul dintr-un 
punct arbitrar a unei date video sau a unei secvenţe de sunet comprimat. 

Deoarece datele multimedia sunt semistructurate, semantica entităţilor este funcție de 
semantica părților componente. Fiecare componentă a unei entităţi multimedia are atribute şi 
poate participa în relaţii. Aceste atribute şi relaţii se împart în două tipuri: cele ce utilizează 
proceduri corespunzătoare de decodificare şi cele care nu folosesc astfel de proceduri. 
Atributele si relaţiile a căror prezență depinde de aplicarea unui procedeu de decodificare sunt 
bazate pe context în timp ce celelalte sunt de context. Atributele şi relaţiile 
dependente de context se împart la rîndul lor în informaţii de legătură şi noninformaţii de 
legătură. Un atribut este informaţie de legătură dacă nu este explicit codificat în entitatea 
multimedia respectivă. Prezența acestui tip de atribut sau relație adaugă noi informaţii cu 
privire la o anumită entitate multimedia, informaţii ce nu pot fi derivate dintr-o codificare 
binară. De exemplu, numele unei clădiri afişat într-o imagine ar putea fi informaţie de 
legătură bazată pe context. Diferenţa între informaţia de legătură şi noninformaţia de legătură 
este destul de mică şi puțin conturată. Ca opinie generală, ea ar consta în accea că informaţia 
apare în reprezentare binară sau nu într-o anumită entitate multimedia. Utilizarea relaţiilor si a 
atributelor bazate pe context determină extinderea semnificativă a unor tipuri de operatori 
cum ar fi filtrarea si navigarea ce pot fi folosite de utilizator. - 


15.2. Un model generic al datelor multimedia 


Înainte ca informaţia să fie manipulată într-o bază de date ca trebuie mai intii să fie 
reprezentată la nivel logic, independent de arhitectura bazei de date utilizată. Modelul logic al 
informaţiei multimedia va fi adaptat bazei de date respective. De aceea, pentru acest tip de 
informaţie se preferă o arhitectură de bază de date orientată obiect; deci va trebui să se 
reprezinte informaţia multimedia utilizînd modelul orientat obiect. Sunt astfel cinci tipuri de 
informaţii care ar trebui reprezentate într-un astfel de model: 

- Informaţii multimedia neinterpretabile care sunt de obicei reprezentate printr-un 

bloc (binary large obiect) adică un obiect de dimensiuni mari in format binar; 

- Informaţii i de context sunt cele care sunt folosite la sincronizări video 
(între cadre de imagine şi audio), cele care se află în antetul fişierelor şi conțin 
informaţii ce caracterizează diferitele entităţi multimedia cum ar fi cele referitoare 

la metoda de digitizare si codificare utilizată, procedurile care le realizează etc; 
- Informații alfanumerice care se află în baze de date convenţionale şi privesc 
proprietăţile si relaţiile între diferitele entităţi ce nu sunt multimedia. 
- Informajii ce realizează legătura între obiectele multimedia şi cele de alt tip; sunt 
exemplificate prin entităţile care apar în anumite cadre, date video dependente de 
context. 
- Informaţii ce definesc modul de construire şi reprezentare a diferitelor legături 
între obiectele multimedia. Ele ar putea fi obținute prin specificarea relaţiilor - 
pornind de la interpretarea datelor multimedia de către utilizator sau ar putea f 
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construite parțial în mod automat utilizând variate tehnici de interpretare a datelor 
Proiectarea unui model pentru un sistem informatic multimedia va trebui să asigure o 
comunicare facilă între datele entităţilor obişnuite ale aplicaţiei şi obiectele multimedia, Un 


iectuale multimedia în termenii caracteristicilor. 

" Caracteristicile obiectelor multimedia pot fi simple sau complexe. Cele complexe pot 
fi descompuse la rindul lor, in timp ce cel p qe rena pig 

Caracteristicile unui obiect multimedia sunt similare atributelor unei entităţi obişni 
este multimedia) a unei baze de date cu informaţii alfanumerice. Există în acest sens o 
Excepție, adică un atribut al unei entități obişnuite poate fi informaţie de legătură în timp ce o 
Caracteristică a unul obiect multimedia, bazată fiind pe context constituie informaţie de 
kaa iui obişnuit i jută la o unică 
i i enti uite este o colecție de atribute care ajută la o unică 
identificare H E E ien inedia poate avea cheia constituită din caracteristici 
dependente de context dar de asemenea poate fi folosită o cheie standard formată din atribute 
te de context. Ca şi în cazul entității obișnuite, cheia unui obiect ajută la 


R z 4 si de 

Cheile dependente de context pot fi utilizate la obținerea unor informaţii legătură 

necesare definirii de relaţii între obiectele multimedia şi entităţile obişnuite. In figura 151 se 

prezintă modul de realizare a unor astfel de relații. O relație între entitatea sene $ îi 
euin : fisa : "b ^ o la 

ultimedia m; a fost anterior stabilită prin definirea unei informaţi x — > 


Obiectul multimedia m, 


Obiectul multimedia mz 
Fig. 15.1. Obţinerea unei relații dependente de context 
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Aceste consideraţii arată cât de important este ca pentru orice model de date 
multimedia să se poată preciza variatele caracteristici şi organizarea lor. O caracteristică a 
unei imagini se poate baza pe textură, culoare, intensitate, geometrie sau alte proprietăți ale 
imaginii. Deoarece un video conţine o secvenţă de cadre (de imagini), caracteristica ar putea 
fi o secvenţă de caracteristici ale imaginilor. 

Sarcina cheii într-un model multimedia este să realizeze legătura între semnificaţia 
domeniului obiectelor si semnificația caracteristicilor. Deoarece caracteristicile sunt 
structurate, semnificaţia unei caracteristici complexe ar trebui să fie dată de semnificaţia 
componentelor ei. Cel mai familiar exemplu este acela de similaritate. Astfel, două obiecte 
multimedia sunt similare dacă setul lor de chei dependente de context sunt similare. 

Modelele multimedia pot avea înţelesuri mai complexe. Se poate evalua o astfel de 
interogare în două moduri diferite, Presupunem că se doreşte obținerea datelor video în care 
două persoane (X si Y) dansează. O cale simplă de realizare a acestei interogări ar fi cea de 
obţinere a tuturor datelor video in care X şi Y sunt în relaţia dans. Această metodă are 
dezavantajul că nu se poate generaliza la alte cazuri care nu au fost specificate de utilizator. 
Un mod mai robust de realizare este acela prin care se defineşte dansul în setul de obiecte a 
domeniului, în termenii unei secvenţe de evenimente din mulțimea caracteristicilor. Relaţia 
între entităţile obişnuite ale aplicaţiei si imaginea lor se poate realiza pe baza informaţiei de 
legătură dependente de context. Practic se urmăresc cadrele contigue ale unui video şi se 
extrag acelea care corespund acţiunii de dans si apoi din cele obținute se păstrează doar cele 
în care acţiunea este desfăşurată de persoanele precizate. Acest mod de realizare a unei 
interogări, prin utilizarea unor tehnici curente de interpretare a imaginii, este destul de greu de 
efectuat în situaţiile în care condiţia devine laborioasă. In cazul în care dansul nu a fost definit 
în modelul original, utilizatorul ar trebui să aibă un set de instrumente pentru a-i permite să 
definească această acţiune. Noţiuni precum mişcarea sincronă a brajelor şi a picioarelor 
combinate cu alte informaţii ar putea defini dansul. Aceasta ilustrează natura incrementală a 

operaţiei de detectare a unei caracteristici complexe, 

Un set bogat de caracteristici de bază si un set de caracteristici pentru diferite operaţii 
ar fi suficiente pentru definirea de caracteristici complexe la orice moment de timp. De 
exemplu, caracteristica intensitatea unui punct poate fi definită ca pi(punct, intensitate) unde, 
pi este un constructor care combină două caracteristici într-o nouă caracteristică complexă. 


15.3. Organizarea bazelor de date multimedia ca 
extensie a celor orientate obiect 


Într-o lume aproape complet eterogenă, cum este cea a bazelor de date multimedia, atit 
sub aspectul datelor combinate cit si a soluţiilor propuse şi platformelor utilizate, identificarea 
elementelor comune care să stea la baza unei organizări unitare este mai mult decit necesară- 
În acest scop se vor pune în evidenţă nivelurile de structurare a bazelor de date multimedia: 

- structura funcțională sau tehnologică, 

-= structura relațională, 

- structura de interogare sau dinamică, 

~ structura de prezentare sau de sistem. 

Structura funcţională sau tehnologică a bazelor de date multimedia are în vedere 
funcţiile de creare, achiziţie, compresie, stocare, manipulare, transmitere la distanţă, 
sincronizare şi combinare a informaţiilor digitale, De obicei, imaginile statice şi datele audio 
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şi video se vor elabora in cazul bazelor de date multimedia, separa: Şi Ezegnms cr SEE 
tradiţionale. Nu se va utiliza pentru aceasta tehnologia analog? ses viză 3emcemiet 
singurele dispozitive corespunzătoare din punctul de vedere ai caz de zc 
memorată (mai cu seamă audio şi video) dar acestea sunt foarte ir ceea e ees 
interogarea şi interactivitatea, de aceea se va utiliza tehnologia di; 2 


. necesare şi tehnici de compresie a fişierelor audio si video. 


Structura relafionalá priveşte aspecte ale corelării statice a or de ere pe cet 
mit O Ur de de n a APA adi atit uut Seppe de circuri este 
eterogen şi poate proveni din medii diverse: date formatate, texte ASCI imaji == 
imagini vectoriale, animații de diferite tipuri, sunet, video etc. edes * 

Obiectele încapsulează operațiile specifice într-un mod cere perie resize crc 
a structurii funcționale. Fiecare tip de obiect va conține me:oie ocazie ze sco 
funcţională. Spre exemplu, vizualizarea unui obiect se face diferea EE cue 
(imagine, text etc.), dar funcţia care realizează vizualizarea poară sosis mams. siccome 


' însă un cod executabil diferit. 


Fiecare obiect are o structură internă proprie, determineză pcs seizzile Sore 
componente. Intre obiecte, chiar eterogene, există conexiuni care s: vw 4 
in obiecte complexe. Gruparea lor în colecţii se poate face manual. secizc3: sez £235 

Structura de interogare sau dinamică include metodele specce 
informaţiei şi modul de interacțiune dintre utilizator și baza de dee : 
gestiune a bazelor de date trebuie să dispună de proceduri pentru sei 
bazate pe tehnica similarități textului, imaginii, sunetului, precum și 
sau aleatoare pe bază de index. Structura de interogare include și o = 
de tip navigational, care permite ghidarea utilizatorului în fiecare zs 
urmat, informaţii deja vizitate, istoricul căutării etc.). 

Structura de prezentare sau de sistem ţine de aspectele spec 
baze de date multimedia, si asigură consultarea bazei de date 
platforma pe care se face vizualizarea. În acest scop, în afara uz 
avansate, baza de date trebuie să dispună de mecanisme care să pezzi 
a obiectelor sau a unor părți din obiectele complexe. Obiectele disp: i 
propriu-zisă şi de informaţie de vizualizare: formate, metode de compresie, 
conversie etc. Baza de date trebuie să dispună de componente pe care să ze să 
corect. Pentru aplicaţiile în timp real, sistemul de gestiune penia beze Se date = 
dispune de primitive de procesare în timp real, care asigură o &: 3 sina 
utilizare eficientă a resurselor de memorie folosind tehnici de bufferizaze sp ie 

Se pot pune în evidență mai multe tipuri de obiecte ce womneini a fi inci; 
modelul multimedia. La cel mai primitiv nivel, un tip de obiect ar zresxz să reprez: 
date de bază cum sunt: text, imagine, audio, video. La un nivel mi 
expliciteze natura spaţială sau temporară a obiectelor multimedia. Exi 
temporale ce caracterizează datele multimedia de tip audio-video. Prima Eum 
la conţinutul datei multimedia, ca o succesiune de cadre în timp, ier cea de-a doua — 
se leagă de etapa de prezentare care trebuie să se facă în timp real. so 

Luând în considerare aceste trăsături specifice obiectelor ce sux: manip: 
bazelor de date multimedia, se pot evidentia particularităţi referitoare ls indexare, s=% 
căutare, interogare şi regăsire bazată pe context. 
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15.4. Sincronizarea în transferul datelor în timp real 


Datele multimedia solicită adesea sincronizarea în procesul de transfer în timp real, 
Este de dorit ca datele să ajungă întotdeauna la receptorul final la timp astfel ca să nu existe 
întreruperi în prezentare. In cazul în care două sau mai multe tipuri de date sunt extrase pentru 
prezentare, poate apărea o problemă de sincronizare la receptorul final. In cazul asocierii de 
video, voce şi text de titraj, toate cele trei tipuri de date trebuie să fie sincronizate, adică să 
ajungă împreună la receptorul final. 

Transferul în timp real şi sincronizarea vor depinde de distribuţia ratelor de compresie 
a diferitelor tipuri de date, spaţiu tampon alocat, algoritmii de planificare utilizaţi, plasarea 
datelor pe dispozitivele de memorie secundară, distribuia datelor pe dispozitivele de reţea şi 
lărgimea de bandă alocată în canalul de comunicaţie. Unii cercetători au adoptat abordarea 
găsirii condiţiilor ce garantează transferul în timp real şi sincronizarea informaţiei la 
receptorul final. Este mai uşor de realizat acest lucru cînd receptorul se află pe aceeaşi staţie 
de lucru. Dificultatea apare cînd receptorul este într-un nod al reţelei datorită 
impredictibilităţii încărcării reţelei. In acest caz se va sacrifica o parte a cantităţii de 
informaţie în ideea garantării livrării în timp real şi a sincronizării. 

Evoluția tehnologică va duce la creşterea vitezei dispozitivelor de memorare 
secundară, cît şi a canalelor de comunicaţie. Tehnologia fibrelor optice promite să livreze sute 
de megabifi pe secundă. Totuşi, s-a dovedit că utilizatorii consumă orice extra resursă ce li se 
oferă. Astfel este important să se dezvolte şi să se studieze algoritmi ce garantează o livrare 
bună în timp real prin sincronizarea informaţiilor multimedia. Algoritmii ar putea exploata 
reducerea de calitate cit şi utilizarea memoriei cache pe rețea şi ar putea utiliza modele 
orientate pe performanță cit şi modele utilizator de absorbţie. 


15.5. Navigarea şi interogarea bazelor de date 
multimedia 


Procesul de interogare a unei baze de date multimedia are o serie de particularităţi în 
special datorită naturii informaţiilor ce pot conţine text, imagine, audio şi video. In acest sens, 
sistemul trebuie instruit în ce priveşte modul de prezentare a rezultatelor interogării. O altă 
particularitate derivă şi din faptul că informaţiile în bazele de date multimedia nu sunt 
structurate ca în bazele de date standard. In plus, nu se cunoaşte cu siguranță ce fel de date 
multimedia există în respectiva bază de date, de aceea formularea cererii devine foarte 
importantă. 

Pentru a rezolva aceste probleme se propune modelarea procesului de interogare ca pe 
o secvență de operaţii de filtrare si navigare. Intreaga bază de date multimedia poate fi logic 
reprezentată de o rejea sau un graf. Nodurile unei astfel de rețele corespund entităţilor ce pot 
fi obişnuite: imagine, video, audio, în timp ce arcele reţelei corespund relațiilor între aceste 
entități. O operație de filtrare pe o astfel de reţea produce o subrejea eliminind entitățile şi 
relaţii nedoritele. Pe de altă parte, operaţia de navigare permite utilizatorilor să citească 
textual informaţia, să vizualizeze o înregistrare video, să asculte o secvență audio sau să 
urmeze o anumită rută din rețeaua dată, trecînd de la o entitate la alta. Pentru a se înţelege 
modul de operare se va considera exemplul în care un utilizator navighează printr-o secvenţă 


de imagini în care apar diferite tipuri de tractoare. In una din ele se recunoaşte si o combină. .—. 
sien eb NI fuck eru un ee ti M ceci. avea a 
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model de combină. In àcest caz, sistemul poate prezenta informații alfanumerice privind acea 
combină. El poate disponibiliza o serie de obiecte multimedia, pentru a fi consultate, în care 
apar alte modele de combine. Dacă utilizatorul doreşte să vadă proiectanți unei combine 
atunci sistemul poate construi o secvență de obiecte multimedia în care respectivi proiectanți 
apar. Abordarea extragerii de informație sugerează că o entitate poate fi extrasă deoarece este 
relevantă, deşi ea poate să nu constituie o valoare sau o relație care să apară în mod explicit în 
interogarea utilizatorului. 

Recent, evidențierea a fost introdusă în abordările bazate pe hypertext şi hypermedia. 
Abordările hypertext şi hypermedia sunt căi de structurare a conținutului bazei de informație. 
Informaţia este extrasă traversînd legături de un tip particular, înainte si înapoi. Modelul de 
date hypertext / hypermedia este foarte apropiat modelelor bazelor de date orientate obiect. 
Modelele orientate hypertext / hypermedia adesea sugerează o metodă de navigare în scopul 
extragerii informațiilor din baza de informare. 

În sistemele informatice standard toate cererile sunt alfanumerice iar în cele 
multimedia, obiectele multimedia pot participa la orice interogare. Deoarece un modul de 
procesare a caracteristicilor extrage caracteristicile tuturor obiectelor multimedia inserate, 
acesta poate extrage caracteristicile similare ale unui obiect multimedia ce este parte a unei 
interogări. Acest mecanism poate fi sugerat în figura 15.2. 

[__] obis matisi 


Inserarea obiectelor 
parte a interogării 


multimedia 


Fig. 15.2. Un obiect multimedia ca parte a unei interogări 


Toate interogările complexe pot fi descompuse in componente elementare ce ar putea 
fi împărțite în patru tipuri. Primul tip de cerere elementară determină toate imaginile cu un 
subset de caracteristici avînd valori cunoscute. Al doilea tip de interogare elementară găseşte 
toate imaginile ale căror set de valori a caracteristicilor furnizează un număr ce aparține unui 
domeniu dat. Al treilea si al patrulea tip includ un obiect multimedia asociat, dat de utilizator. 
În al treilea tip, utilizatorul furnizează metode variate de calcul pentru caracteristicile 
necesare. Al patrulea tip utilizează modulul de procesare a caracteristicilor pentru calculul 
caracteristicilor obiectului multimedia implicat în formularea interogării. 

În realitate, în procesul de interogare, găsirea unor caracteristici care să se potrivească 
exact cu cele ale obiectelor ce se află în baza de date multimedia produce rareori ieşiri utile. 
Astfel, fiecare caracteristică ar trebui să aibă definită propria noţiune de similitudine. Pentru 
că nu este vorba de o similitudine în sensul strict al cuvîntului se va folosi mai bine termenul 
de apropiere. Apropierea dintre două obiecte multimedia ar trebui să se calculeze pe baza unui 
grad mediu de apropiere între componentele lor. Deoarece caracteristicile extrase se bazează 
pe tehnici de interpretare a imaginilor şi pe recunoașterea sunetelor, rezultă că fiecărei 
caracteristici extrase ar trebui să-i corespundă un factor de siguranţă care să exprime faptul că 
acea caracteristică este relevantă pentru procesul de comparare. Acest factor de siguranță ar 
trebui să influențeze viitoarele calcule de similaritate. 
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Pentru a economisi timp se pot obține toate obiectele multimedia având caracteristici 
aparținând unui set dat de caracteristici. Acest concept poartă denumirea de indexarea 
caracteristicilor şi este similar unui index standard care determină obținerea tuturor 
înregistrărilor având o valoare dată pentru un atribut. Majoritatea tehnicilor au la bază 
modelul. Scopul unui astfel de sistem este de a ila descrierea fiecărui obiect 
multimedia cunoscut, numit model, apoi utilizarea acelui model la identificarea oricărui obiect 
multimedia prezent în formularea interogării. Un model pentru un obiect multimedia este 
dezvoltat utilizând caracteristicile extrase de la unul sau mai multe prototipuri ale acelui 
obiect. Au fost propuse mai multe astfel de tehnici: 

- Tehnica model-by-model utilizează fiecare din modelele precompilate, pe rând, ca 
pe un model de test. Sistemul caută pentru obiectul multimedia implicat în 
interogare una sau mai multe caracteristici al obiectului de test considerat. In cazul 
în care o caracteristică se potriveşte, atunci el preia o instanţă a obiectului 
multimedia si estimează proprietăţile acelui obiect. In final se verifică prezența 
obiectului multimedia considerat. Principalul dezavantaj al acestei tehnici este dat 
de costul ridicat cauzat de o căutare exhaustivă a unei date imagine pentru o 
caracteristică selectată, aparţinând unui model de test. 

- O altă cale numită feature-by-feature, formează o colecţie de caracteristici a 
tuturor modelelor. Tehnica asociază fiecărei caracteristici o listă conţinând 
obiectele multimedia în care aceasta s-a regăsit. Se caută apoi pentru fiecare 
caracteristică, obiectul multimedia implicat în interogare. Dacă se găseşte o 
anumită caracteristică, se consultă lista aferentă ei pentru a face o ipoteză şi apoi se 
verifică identitatea şi locaţia posibilului obiect. Găsirea unor astfel de caracteristici 
necesită metode complexe şi costisitoare care trebuie să fie repetate de fiecare dată 
când un model este şters sau inserat. 

Figura 15.3 ilustrează diferențele fundamentale între cele două metode. Modelul 
model-by-model (figura 15.3 a) utilizează o caracteristică aparținând unui model dat, în timp 
ce modelul feature-by-feature (figura 15.3 b) utilizează o caracteristică aparținând unei 
colecţii de caracteristici, obţinută dintr-o bază de date de modele. 

Pentru implementarea acestor tehnici se pot folosi proceduri preluate din gestiunea 
datelor convenţionale care duc la o creştere a vitezei de regăsire a informaţiei. De exemplu, se 
pot utiliza căutări binare pe seturi de date sortate, în plus operaţiile de căutare vor fi 
completate cu cele de inserare si ştergere care sunt necesare; datele pot fi organizate folosind 
structuri de date necesare stocării şi indexării preluate de la sistemele de gestiune a bazelor de 
date convenţionale. În plus, s-au făcut eforturi de a furniza o adresare după conținut pentru 
tipuri complexe de date, de exemplu imaginile. Deoarece este dificil să accesăm informaţia în 
timp real utilizând tehnicile de recunoaştere a paternelor, cea mai mare parte a metodelor 
furnizează un descriptor de conţinut pentru imagine care este examinat în comparaţie cu o 
cerere de utilizator. Descriptorul de conţinut poate fi un simplu text, sau poate conține 
informaţie structurată ce descrie conţinutul imaginii. În unele cazuri, tehnicile de extragere 
bazate pe similitudine pot fi folosite pentru a potrivi conținuturile bazei de date cu un filtru 
grafic furnizat de utilizator. În mod curent, extragerea bazată pe conținut pentru documentele 
scanate sau voci este limitată de capacităţile vorbirii curente şi a tehnologiei de recunoaştere a 
documentelor. Domeniul adresării pe conținut a obiectelor multimedia este profund. El 
cuprinde probleme dificile din ştiinţa calculatoarelor şi ingineriei, cum ar fi înţelegerea 
limbajului natural, procesarea vorbi, ionarea şi modelarea utilizator. Adresarea după 
conținut trebuie suplimentată cu tehnici de parcurgere rapidă (de exemplu utilizarea 
miniaturilor), deoarece este posibil ca în unele medii utilizatorul să nu fie capabil să specifice 
precis ceea ce doreşte. 
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(b) 
Fig. 15.3. Diferențe între modele 


15.6. Gestiunea şi procesarea fluxurilor media în 
baze de date multimedia 


pentru gestiunea tipului media. n 

ial ort o componentă care extinde funcționalităţile sistemului de 8: 
bazelor de date Oracle permiţând stocarea, gestiunea şi regăsirea datelor mulis 
imaginilor, a secvențelor video, a datelor audio gi a altor tipuri media eterogene, înc” 
manieră integrată cu tipuri de date tradiționale. Oracle interMedia nu esum 
dispozitivele de captură multimedia și nu are funcţii pentru redarea datelor multizcesia = 
facilitează gestiunea datele multimedia stocate în baza de date, E 

nterMedia gestionează datele multimedia stocate în baza de date sub forma BIOS 
urilor (binary large objects), a fişierelor multimedia gestionate direct de sistemul de opera. 
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formatul utilizat in acest caz este BFILE (file-based large objects) si a datelor multimedia 
stocate pe un server web. 

nterMedia foloseşte tipuri obiectuale pentru descrierea datelor multimedia, astfel; 

- tipul ORDAudio pentru datele audio; 

- tipul ORDImage pentru imagini statice; 


Toate aceste tipuri conţin şi informaţii despre sursa datelor, tipul de dată folosit fiind 
ORDSource. 

Recunoaşterea imaginilor bazată pe conţinut este o problemă importantă asociată 
sistemelor de gestiune a bazelor de date multimedia. Odată cu creşterea volumului colecțiilor 
imaginilor digitale care pot fi eventual stocate în baza de date, creşte si dificultatea regăsirii 
imaginilor relevante. Pentru rezolvarea acestei probleme există două metode şi ambele 
utilizează metadate pentru regăsirea imaginilor: 

- prima utilizează informaţii introduse manual în tabele, ca de exemplu: titluri, 
cuvinte cheie descriptive preluate dintr-un vocabular limitat și scheme de 
clasificare predefinite, 

a doua foloseşte caracteristicile imaginilor, caracteristici extrase automat si 
recunoaşterea obiectelor pentru clasificarea conţinutul imaginii. 

InterMedia permite combinarea celor două alternative prin proiectarea unei tabele ce 
conţine imagini. Pentru aceasta se folosesc date de tip text pentru descrierea semnificației 
semantice a imaginii şi tipul de dată ORDImageSignature pentru interogări bazate pe conţinut 
ce folosesc atributele esenţiale ale imaginii. Un sistem de recunoaştere bazat pe conţinut 
prelucrează informaţiile din imagine şi creează o abstractizare a conţinutului pentru atributele 
vizuale, Interogările lucrează cu abstractizarea imaginii şi nu cu imaginea propriu-zisă. 

Criteriile de căutare folosite de InterMedia sunt culoarea, textura şi conturul. Poziţiile 
acestor atribute vizuale în cadrul imaginii sunt reprezentate prin coordonate. Aceste 
coordonate nu sunt folosite in mod independent pentru recunoaşterea formelor ci doar 
împreună cu unul din cele trei atribute vizuale. 

Imaginea odată inserată în baza de date este analizată şi este stocată câte o 
reprezentare compactă a conținutului sub forma unui vector de caracteristici numit semnătura 
imaginii. Semnătura imaginii este extrasă prin segmentarea acesteia în regiuni, pe baza petelor 
de culoare care compun imaginea. Fiecare regiune are asociate informaţii despre culoare, 
textură şi contur. Semnătura confine aceste informaţii pentru fiecare regiune care formează 
imaginea şi informaţii despre culoare, textură şi contur pentru reprezentarea acestor atribute în 
întreaga imagine. 


Atributul culoare memorează informaţii despre distribuţia culorilor în întreaga 
imagine. Această distribuție conține date despre intensitatea fiecărei culori, 

Atributul fexturd reprezintă şabloanele din cadrul imaginii, precum granularitatea și 
smoothness. Spre deosebire de atributul contur, textura este foarte sensibilă la caracteristicile 


Locaţia reprezintă poziţia componentelor culoare, textură şi contur. 
imaginilor stocate într-o bază de date se face prin compararea lor cu o 
imagine model care poate fi o imagine stocată în baza de date, din afara bazei de date sau o 
imagine vectorială. 
În procesul de căutare, se atribuie o pondere fiecărui atribut vizual în funcţie de 
importanța lui. Valoarea fiecărei ponderi reflectă cát de sensibil trebuie să fie procesul de 
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căutare faţă de un anumit atribut. Valorile ponderilor trebuie să fie între O (atribut 
nesemnificativ) şi 1 (atribut extrem de important în procesul de căutare). 

Asemănarea dintre două imagini pentru fiecare atribut vizual este calculată ca scorul 
sau distanța dintre imagini, respectând atributul. Scorul ia valori în intervalul 0 (nu există 
diferență) — 100 (diferenţă maxim posibilă). Scorul întregii imagini se calculează ca sumă a 
scorurilor atributelor ponderată cu importanța fiecărui atribut. 

În procesul de căutare se foloseşte o valoare — prag de semnificaţie. Dacă suma 
ponderatà este mai mică sau egală cu valoarea pragului atunci imaginile se potrivesc, altfel 
nu. 

Pentru creşterea vitezei de căutare în bazele de date de mari dimensiuni care conţin 
date multimedia este utilă crearea şi utilizarea unui index folosit pentru căutarea printre 
semnăturile imaginilor. Pentru aceasta se foloseşte un index de domeniu sau index extensibil 
deoarece acesta suportă obiecte complexe. Baza de date Oracle şi interMedia cooperează 
pentru definirea, construirea şi întreţinerea unui index pentru datele de tip imagine, index de 
tip ORDImagelIndex. Odată creat, indexul este automat actualizat ori de câte ori imaginile sunt 
inserate, modificate sau șterse din baza de date. Datele indexului sunt stocate în două 
tablespace-uri care trebuie create în prealabil: unul care conţine datele indexului curent şi 
celălalt este un index intern creat pe aceste date. 

Recunoaşterea formelor este o procedură complexă. Algoritmul de recunoaştere a 
formelor implementat în Oracle poate fi folosit cu succes dacă sunt îndeplinite anumite 
condiţii si anume: 

- dacă obiectul căutat ocupă o parte semnificativă a imaginii, 

- dacă nu există elemente irelevante suprapuse peste o parte a obiectului căutat, 

- dacă obiectul căutat se află în aceeași parte a imaginii 

-  dacà dimensiunile relative ale obiectului in cele 2 imagini, imaginea de referinţă si 


cea în care se face căutarea sunt apropiate, 

- dacă obiectul căutat este fotografiat din acelaşi unghi în ambele imagini, 

- dacă obiectele adiacente din imagine au culori distincte, 

dacă imaginea este formată doar din câteva forme simple. 

Pentru a îndeplini aceste condiţii, se pot decupa succesiv zone din imagine, zone în 
care se realizează căutarea si se pot utiliza diferite combinaţii de ponderi ale atributelor 
folosite in procesul de căutare. 

Pentru exemplificarea operaţiilor de crearea a unei tabele cu atribute de tip imagine, 
de inserare a imaginilor în baza de date, de import a imaginilor inserate şi generare a 
semnăturilor pentru imaginile din baza de date, pentru crearea tablespace-urilor pentru index 
şi crearea unui index de domeniu şi căutarea unei imagini în baza de date s-a creat câte o 
procedură PL/SQL. Procedurile au fost testate pe o bază de date Oracle 10g Release 2. Pentru 

realizarea interfeţei cu utilizatorul, apelarea procedurilor stocate şi pentru afişarea rezultatelor 
a consti ODEL UR. 

Se folosește obiectul DIRECTORY pentru administrarea accesului gi utilizarea 
tipurilor de date BFILE. Obiectul DIRECTORY stabileşte un pseudonim pentru un director al 
sistemului de fişiere al severului bazei de date unde se află fişierul care trebuie accesat. Un 
fişier extern bazei de date poate fi accesat numai dacă se stabilesc depturile de acces necesare 
obiectului DIRECTORY. Stabilirea directorului (e: Wmydir) de unde vor fi preluate fișierele de 
tip imagine pentru inserarea lor în baza de date se face prin secvența: 

CREATE OR REPLACE DIRECTORY dirlucru AS 'c:\mydir'; 

GRANT READ ON DIRECTORY dirlucru TO PUBLIC WITH GRANT OPTION; 
Crearea tabelei numită imagini cu structura: 

* idNUMBER- reprezentând id-ul imaginii, 

- descriere VARCHAR2(255) ce contine o scurt descriere a conținutului imaginii, 
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- img de tip ORDSYS.ORDlImage pentru obiectul de ti imagine, 
- ing senn de tip ORDSYS.ORDImageSignsture pentru setunätara imagini, 


(id NUMBER, 

descriere VARCHAR2(255), 

img ORDSYS ORDImage, 

img semn ORDSYS.ORDImageSignature); 
Procedura. care inserează un tuplu in tabelă are ca parametrii: vid — id-ul imaginii, ii, vdescriere — 
CREATE OR REPLACE PROCEDU deny E 

IRE inserare 

TEACH IN VARCHAR2) OER decem i 


BEGIN 

rcr statică init a ORDImage inifializeazà atributul ORDImage 

7-Metoda statică init a ORDImageSignature crează un obiect ORDIma, Signature 
INSERT INTO imagini VALUES (vid, vdescriere, i a 


US ORDImage.init(file,"DIRLUCRU' nfi), ORDSYS. ORDimageSignature.init()); 


Procedura gen semn este folosită pentru generarea semnăturii imaginilor din tabelă: 
SERA TE PROCEDURE gen_semn : că e n 


BEGIN 
DECLARE 
myimg ORDSYS.ORDImage; 
mysig ORDSYS.ORDImageSignature; 
ctx RAW(4000): NULL; 
BEGIN 
-- pentru toate tuplurile 
FORx in (SELECT ID FROM IMAGINI) 


LOOP 
SELECT S.img, S.img. semn INTO myimg, mysi 
FROM imagini S WHERE Sid  x.id FOR UPDATE: 
~ generează semnăturile apelind metoda generateSignature 


mysig.generateSignature(myimg); 
~ încarcă semnătura generată 
UPDATE imagini S 
SET Simg semn = mysig, S img=myimg =xid; 
E e wysig, Simg=i WHERE S.id = x id; 
END; 
END; 


Crearea tablespace-urilor ce vor fi folosite de indexul de domeniu. 


Creare tablespace-urilor pentru index: 
CONNECT system/passadmin; 

GRANT CREATE TABLESPACE TO mar; 
GRANT DROP TABLESPACE TO mar: 
CONNECT mar/passmar; 
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. Crearea indexului de domeniu: 


CREATE INDEX idx imagini ON imagini(img semn) INDEXTYPE IS 
ORDSYS.ORDIMAGEINDEX. 
* PARAMETERS (ORDImage Filter. Tablespace = ordimage. idx. tbs, 1, 
ORDImage Index Tablespace = ordimage, idx tbs 27); 

imagini stocatá in 


Procedura Cautare este folosită pentru cântarea celei mai asemănătoare i 
baza de date, folosind ca imagine de referintă imaginea conținută în fişierul cu numele nfis. 
Procedura are ca parametru de ieşire id-ul imaginii obținute în urma căutării, idrez. 


CREATE PROCEDURE CAUTARE (nfis IN VARCHAR2, idrez OUT NUMBER) 
I 


BEGIN 
DECLARE 

vimage ORDSYS.ORDIMAGE; 

asemn ORDSYS. ORDIMAGESIGNATURE; 
gimg ORDSYS.ORDIMAGE: 


= se creează un cursor pentru selectarea imaginii similare cu cea de referinţă. Operatorul 
IMGSimilar compară semnătura imaginii de referință cu semnăturile imaginilor stocate în 
tabelă si stabileşte dacă ele sunt asemănătoare pe baza valorilor ponderilor și a pragului. 
Imaginile sunt asemânătoare, în condiţiile formulate dacă distanța calculată este mai mică sau 
egală cu valoarea pragului, caz în care operatorul JMGSimilar returnează 1. S-au folosit 
următoarele ponderi pentru atribute: locaţie *1 e cel mai important atribut, culoarea=0,9, 
formar=0,8 iar textura-0, - cel mai puțin important atribut. 

CURSOR getimg IS 

SELECT id, img FROM imagini WHERE 

ORDSYS IMGSimilar(img_semn, qsemn, 

'color-"0.9" texture="0. 1” shape=="0.8" location="1", 5) = 1; 

BEGIN 

idrez:=0; 

~ Iniţializează şi setează proprietăţile obiectului imagine 

qimg := ORDSYS.ORDIMAGE init('FILE''DIRLUCRU'nfis); 

qimg.setproperties; 

~ Iniţializează obiectul semnătură 

qsemn :* ORDSYS.ORDIMAGESIGNATURE. init(); 

— Crează un obiect temporar pentru BLOB-ul obiectului semnătură 
DBMS_LOB.CREATETEMPORARY(gsemn signature, TRUE); 

— Generează o semnătură pentru imaginea folosită la căutare 
qsemn.generateSignature(qimg); 

OPEN getimg; 

LOOP 

— stochează valorile id-ului şi img pentru tuplul care îndeplineşte condiţia de asemănare 
definită 
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FETCH getimg INTO idrez, vimage; 

EXIT WHEN getimg?sNOTFOUND; 

END LOOP; 

CLOSE getimg; 

DBMS LOB.FREETEMPORARY(qsemn signature): 
END; 

end; 


Procedura READIMG este folosită pentru afişarea, în aplicaţia CH, a conţinutului imaginii 
preluate din tabelă. Datorită volumului relativ mare al imaginilor, datele de tip imagine s-au 
manipulat ca BLOB-uri ceea ce permite utilizarea în aplicaţia C£ a imaginii stocate în format 
ORDImage. 

CREATE PROCEDURE READIMG(vid IN number, flux OUT BLOB) 


DECLARE. 

obj ORDSYS. ORDimage; 

numbytes BINARY INTEGER : 32767; 

staripos integer : 1; 

read cnt integer := l; 

ctx RAW(4000) := NULL; 

BEGIN. 

SELECT img INTO obj FROM imagini WHERE id = vid; » 
obj.readFromSource(ctx,startpos, numbytes flux); 

startpos := staripos  numByt. 
read cnt := read cnt 1; 
EXCEPTION 

WHEN NO DATA FOUND THEN 
DBMS OUTPUT.PUT LINE('Sfarsit '); 
END; 

End; 


Secvența de cod scrisă într-o aplicaţie CH de tip WindowsForm pentru testarea 

procedurilor stocate, definite anterior, se poate structura astfel: 

~ declararea unui obiect pentru a realiza conexiunea la o baza de date Oracle: 
private OracleConnection con; 

= realizarea conexiunii la baza de date: 
string myConnString = "User ID=Mar; Password=ciab1 100; Data Source--Oracl;"; 
con=new OracleConnection(myConnString); 

- metoda de inserare a unui tuplu in baza de date: 
private void Inserare_Click(object sender, System.EventArgs e) 
f 


con.Open(); 
ofd.ShowDialog(; 
OracleCommand cmd=new OracleCommand(" SELECT count(*) FROM 
mar.imagini" con); 
object dr-cmd.ExecuteScalar(); 
//apelul procedurii stocate pentru inserarea unei inregistrari in baza de date ` 
OracleCommand cmdins=new OracleCommand("inserare",con); 3 
emdins.CommandType = CommandIype.StoredProcedure; > 
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emdins. Parameters Add("vid" OracleDbType.Int32); 
cmdins. Parameters. Add("vdescriere" OracleDbType.Varchar2,255); 
emdins.Parameters. Add("nfis", OracleDbType. Varchar2,24); 
emdins.Parameters[0]. Value =nid; 

emdins.Parameters(1]. Value 7descr.Text; 

char [] c-new char[1]; 

e[0]- ^; 

string [] nf-new string[100]; 

nf-ofà FileName.Split(c); 

emdins.Parameters[2]. Value nfTnf.Length-1]; 

cmdins. ExecuteNonQuery(); 

con.Close(); 


- apelul procedurii gen emn pentru importul imaginilor din fişierele externe in baza de 
date si generarea semnăturilor necesare regăsirii: 
private void Semnaturi. Click(object sender, System.EventArgs e) 


f 
con.Open(); 
Oracle Command cmdsemn=new OracleCommand("gen. semn",con); 
cmdsemn. CommandType = CommandType.StoredProcedure; 
try 
Z 
int nr-cmdsemn. ExecuteNonQuery(; 


$ 
catch (OracleException ex) 
í 


MessageBox.Show(ex. Message); 
con.Close(); 
} 
- metoda pentru cautarea imagini în baza de date prin parametrizarea indicatorilor de 
private Siaa ikeje sender, System.EventArgs e) 
( ofd ShowDialog(); 


con. : 
OracleCommand cmdcaut-new OracleCommand("cautare", con); 
cmdcaut.CommandType = CommandType.StoredProcedure; 
emdcaut. Parameters Add("nfis", OracleDbType. Varchar2); 
cmácaut. Parameters. Add("idimg", Oracle DbType.Int32); 
cmdcaut. Parameters[0]. Direction Parameter Direction. Input; 
emdcaut.Parameters[1].Direction-ParameterDirection. Output; 
object d=new object); 

char [] c=new char[1]; 

e[0]-^V; 

string [] nf-new string[100]; 

nf-ofd FileName.Split(c); 

emdcaut.Parameters[0].Value =nf[nf Length-1]; 


try 


d =cmăcaut. ExecureScalar(); 
se (Oracle.DataAccess.Client. OracleException ex) 
: MessageBox Show(ex Message); 
A ((int)emdcaut Parameters[1). Value! -0) 


OracleCommand cmáfiex-new OracleCommand("readimg con); 
emáflux CommandType- CommandType.StoredProcedure. 
cmdflux Parameters Add("vid" OracleDbType.Int32). 


emáflux. Parameters Add("flux", OracleDbType. Blob, 30000000,d ParameterDi 


rection. Output); 

emáflux Parameters[0) Direction ParameterDirection Input; 

emáftux. Parameters[1].Direction-ParameterDirection. Output; 
Pb Value*cmácaut.Parameters1] Value; 


d -cmáflux ExecuteScalar(); 
i (Oracle Exception ex) 
MessageBox Show (ex Message); 


Oracle.DataAccess.Types. OracleBlob 

17 (Oracle DataAccess.Types.OracleBlob)emdflx. Parameters[1] Value: 
Bitmap bmp-new Bitnap((System 1O.Siream])): eii 
pb. Image bmp; 

pb Height-bmp Height: 

pb. Width bmp. Width; 

2 


else 

[i 

pb.Inage-null; 

Mesegetos Shoe" exista nici o imagine asemanatoare!"); 


con.Close(); 
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16.1. Elemente introductive 


Plasarea pe Intemet a unor colecții complexe de informaţii presupune stocarea 
acestora în baze de date care pot fi apoi accesate online de către utilizatori. Termenul de “bază 
de date online” poate fi uşor înşelător, deoarece în realitate sistemul care face vizibilă această 
bază de date pe Internet este mult mai complex. 

Nu există o definiţie unanim acceptată a bazelor de date online însă denumirea se 
referă la acele baze de date al căror conţinut poate fi accesat în timp real pe Internet, 

Orice bază de date care oferă informaţii utilizatorilor de servicii Internet trebuic 
stocată pe un server care este vizibil pe Internet si să folosească o tehnologie de acces la baza 
de date, 

La ora actuală, majoritatea covârșitoare a bazelor de date online sunt accesibile prin 
intermediul paginilor web. Tehnologiile anterioare bazate pe aplicaţii scrise în limbaje de 
nivel înalt sunt rar folosite la dezvoltarea aplicaţiilor noi. Există o tendinţă ce se conturează 
tot mai intens de a oferi acces la bazele de date prin intermediul serviciilor web. Această 
modalitate, ce foloseşte principiile SOA(Service Oriented Architecture), se extinde continuu 
însă s-a răspândit puţin până în momentul de faţă. Pe parcursul acestui capitol vom prezenta 
tehnologiile de acces la bazele de date online folosind paginile web. 

Informaţiile din baza de date online trebuie extrase în conformitate cu nevoile 
specifice ale utilizatorului si apoi formatate astfel încât să fie corect afişate. Spre exemplu, 
când cineva scrie cuvântul “România” pe motorul google.com sistemul va prelua solicitarea 
din formularul de căutare, va caută în baza de date elementele în care apare cuvântul 
“România” după care va formata aceste rezultate astfel încât ele să poate fi afişate de un 
browser precum Internet Explorer. 

Magazine on-line, forumuri de discuţii, comunităţi online până la site-uri B2B sau 
B2C, sunt exemple de aplicaţii online care utilizează baze de date pentru generarea dinamică a 
paginilor, crearea de conturi virtuale, creare de statistici şi multe alte facilităţi. Pentru unele se 
realizează propria bază de date, altele utilizează baze de date deja existente, la care se 
conectează si preiau informaţiile necesare. 

Din punct de vedere al tehnologiilor, orice SGBD poate fi folosit pentru a pune o bază 
de date online. Totuși s-a observat că unele SGBD-uri, în mod special Fox Pro şi Access, au 
rezultate foarte slabe şi nu sunt recomandate. Pentru baze de date online cele mai folosite 
SGBD-uri sunt: ORACLE, SQL Server şi MySQL. 

Bazele de date online pot fi instalate atât pe sisteme Windows cát și pe oricare din 
sistemele de operare din grupa Unix/Linux. Sunt preferate adesea sistemele de operare Linux 
datorită costului redus la care aceste sisteme de operare reuşesc să ofere performanțe ridicate. 

O vedere generală a arhitecturii serverului este oferită în figura 16.1. După cum se 
observă din schema de mai sus, arhitectura sistemului este structurată pe mai multe nivele. În 
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momentul cand utilizatorul extern doreşte să acceseze informaţii situate pe server, el va folosi 
un browser Internet pentru a se conecta la acesta. Accesarea serverul se face prin intermediul 
unui URL. 


contin date utile 


Fig. 16.1 Arhitectura unui server web ce deserveşte o bază de date online 


Elementele principale care intră în componenţa arhitecturii serverului sunt: 

- Serverul de web care este o aplicaţie complexă responsabilă pentru comunicarea cu 
browserele externe. Practic serverul de web asculta portul HTTP al maşinii pe care 
este instalat. În momentul când sosește o cerere pe acest port, serverul de web o 
interpretează pentru a vedea ce informaţii au fost solicitate, iile solicitate 
de la server sunt de fapt fişiere care se află pe hard-disk. Serverul de web are rolul 
de a împacheta aceste fişiere, astfel încât ele să poată fi trimise mai departe. 
Fișierele solicitate pot fi imparjite în două categorii: 

» Fişiere care conţin informaţii statice. Acestea se transmit mai departe 
către browsere fără nici un fel de modificare. Fişierele statice sunt de 
obicei imagini, fișiere HTML, filme, documente oferite spre download, 
filme Flash etc. 


documentelor de tip HTML face posibilă accesarea bazelor de date pe 
Internet. 
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- Înterpretorul de scripturi tip server-side. Are rolul de a executa scri 
serverului de web, de a prelua rezultatul unor interogàri la a satie Gan 
şi de a trimite spre serverul de web rezultatul execuției scripturilor. În momentul 
când serverul de web ise solicită rularea unui script, acesta identifică în funcţie de 
extensia fişierului, care din compilatoare trebuie să ruleze scriptul respectiv. În 
cazul în care un script are nevoie de înregistrări dintr-o bază de date, acesta va 
interacționa cu ea prin intermediul unui driver. El va executa în SQL o cerere la 
nivelul bazei de date. În urma execuţiei acestei cereri i se retumează un cursor. 
Prelucránd acest cursor se generează cod HTML care odată ajuns la un browser 
determină afişarea datelor dorite. Fiecare interpretor de scripturi se asociază unui 
limbaj de server-side scripting. Limbajele populare ale momentului sunt: 
PHP(Personal Home Pages) și ASP(Active Server Pages). ASP.NET este o 
versiune extinsă a ASP lansată de compania Microsoft în 2002 care tinde să 
înlocuiască clasica tehnologie ASP pe platformele Windows. La acestea se mai 
adaugă şi o serie de alte tehnologii de interes mai restrâns, 

-  Driverele de acces la baza de date au menirea de a mijloci interacţiunea dintre 
interpretorul de scripturi şi baza de date propriu-zisă. Ele sunt instrumente 
software foarte specializate care de obicei nu sunt vizibile nici programatorului 
nici utilizatorului. Driverele sunt importante deoarece alegerea lor eronată 
afectează semnificativ performanţele sistemului. 

- SGBD-ul (sistem de gestiune a bazelor de date) relational care fie este instalat pe 
maşina pe care se află serveul de web, fie este accesibil prin rețea sau Internet 
(nerecomandat). Pentru aplicaţiile web complexe este nevoie de SGBD-uri de mare 
performanţă capabile să “ruleze multe cereri simultan. Principalele SGBD-uri 
folosite în aplicaţiile web sunt:mySQL, SQL Server si Oracle. 

- Colecțiile de fişiere sunt informaţii cu caracter static care sunt trimise utilizatorilor 
la cerere. 


16.2. Interfete de acces 


16.2.1. Pagini Web dinamice 


Principala interfață cu bazele de date online sunt paginile web generate dinamic. 
Paginile Web dinamice sunt folosite atunci când se doreşte modificarea dinamică, a 
conţinutului paginilor Web. Paginile Web realizate în HTML au dezavantajul că sunt statice, 
conţinutul lor neputând fi modificat odată ce au fost încărcate pe un server, decât aducându- 
le înapoi pentru a fi editate. Acest lucru este o problemă serioasă având în vedere că operaţia 
este mare consumatoare de timp. În plus, lucrul cu baze de date nu este posibil în cazul 
paginilor statice. 

Spre exemplu, dacă avem un site de Web format doar din pagini HTML care 
afişează notele şi mediile studenţilor pe serii şi pe grupe şi vrem să mai adăugăm încă un 
student va trebui să modificăm atât pagina grupei cát şi pagina seriei, precum şi pe cele de 
medii. Acest fapt este neplăcut şi îngreunează foarte mult munca. 

Soluţia care se adoptă în astfel de situaţii este plasarea informaţiilor într-o bază de 
date şi accesarea lor ori de câte ori se cere acest lucru de cineva. Mai exact, în loc să se 
creeze 3-4 pagini Web în HTML care să fie modificate ori de câte ori apare o schimbare, se 
va crea o bază de date şi câteva scripturi pe partea de server ce vor construi dinamic paginile 


437 


HTML care vor fi afişate. Schimbările se vor face doar la nivelul bazei de date, ceea ce e 
mult mai simplu. 
; Paginile Web se clasifică în funcţie de natura conținutului in pagini statice si pagini 
dinamice, 
Principalele caracteristici ale paginile Web statice sunt: 
- conțin doar elemente HTML; 
- codul sursă vizualizat în navigator este identic cu cel al fişierului stocat pe disc; 
- nu oferă interactivitate, 
Paginile Web dinamice se caracterizează prin următoarele: 
- conținutul lor este creat dinamic și poate diferi la accesări diferite. De exemplu, la 
bea URL, ree pagini ecran varia in rid de anumiți parametri cum a 
locaţia a lizat inile vizitate anterior, 
vete m i eS zt 
- oferă interactivitate; 
- posibilități de interacțiune. 
În funcție de locul în care este evidențiat caracterul dinamic al paginilor există pagini 
dinamice pe parte de client si pagini dinamice pe partea de server. 


16.2.2. Pagini dinamice pe partea client 


Există mai multe tehnologii care permit realizarea de pagini dinamice pe partea 
de client. Dintre acestea se enumeră: 

- scripturi pe partea de client (client side scripts) ; * 

- DHTML (Dynamic HTML); 

- Applet-uri Java; 

-Controale ActiveX; 

- Elemente multimedia 

Scripturile pe partea de client (client side scripts) sunt secvențe de program incluse 
în pagina HTML care se execută de către navigator. Secvenjele de program sunt incluse 
prin marcatorul «SCRIPT» sau în proprietățile anumitor componente HTML ca răspuns la 
diferite evenimente. Limbajele utilizate pentru a realiza scripturi pe partea de client sunt 
JavaScript, Jscript şi VBScript. Secvenţele de program scrise folosind aceste scripturi nu 
oferă acces la resursele sistemului local (fişiere, rețea). Scripturile pe partea de client sunt 
utilizate pentru asigurarea interactivităţii (meniuri), pentru validarea formularelor, pentru a 
crea diferite efecte, pentru efectuarea de calcule, diverse elemente de animaţie etc. 

DHTML (Dynamic HTML) este o tehnologie dezvoltată de Microsoft care combină 
HTML, foi de stiluri (CSS) si script-uri pentru a realiza pagini Web dinamice sau 
interactive. Permite utilizatorilor să interacţioneze cu pagina fără a retrimite o cerere la 
serverul Web. 


pentru funcționarea acestora este unei maşini virtuale i 
cadrul paginii HTML, applet-urile sunt incluse prin i iul marcatorilor 
<APPLET> sau <OBJECT>. Din applet-urile Java nu este permis accesul la sistemul local 


interactivitate. Sunt asemănătoare applet-urilor, însă spre deosebire de acestea rulează pe 
platforma Windows şi au fost dezvoltate în special pentru Internet Explorer. Controalele 
ActiveX sunt incluse în cadrul paginii Web prin intermediul marcatorului <OBJECT> spre 
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ire de scripturi] de client şi nu au restricţii în-ceea ce priveşte accesul la 
ie ce E de acest tip să fie susceptibile de cod răuvoitor, 
asemănător viruşilor, viermilor sau cailor troieni. De aceea, în cazul în care o pagină 
conține controale ActiveX, navigatorul printr-o fereastră de dialog cere confirmarea 
utilizatorului pentru instalarea si rularea acestora. 

Elemente multimedia sunt dezvoltate în general folosind produsul Macromedia Flash. 
Acestea se prezintă sub forma de fişiere SWF multimedia şi sunt incluse în pagina Web prin 
intermediul marcatorului <OBJECT>. Pentru a putea rula pe partea de client aceste fişiere 
este necesară instalarea unui plug-in denumit Macromedia Shockwave Player. Fişierele 
multimedia Flash se realizează sub forma unor filme, care sunt proiectate cadru cu cadru. 
Acestea oferă diverse efecte multimedia (animaţie, sunet) şi permit interactivitatea cu 
utilizatorul. Sunt utilizate pentru meniuri, jocuri, filme de animaţie etc. 


16.2.3. Pagini dinamice generate pe partea server 

Interpretorul de scripturi tip server-side are rolul de a executa scripturi la cererea 
serverului de Web, de cele mai multe ori de a prelua rezultatul unor interogárila nivelul 
bazelor de date si de a trimite spre serverul Web rezultatul execuției scripturilor sub forma de 
conținut HTML pentru a putea fi afişat de către navigator. In momentul în care serverului 
Web i se solicită rularea unui script, acesta identifică în funcţie de extensia fişierului care din 
compilatoare trebuie să ruleze scriptul respectiv. 


TR 


Fig. 16.2. Generarea paginilor dinamice pe server 


iecărui i ipturi i i i - side scripting. 
Fiecărui interpretor de scripturi i se asociază unui limbaj de server- side 
Limbajele populare ale momentului sunt: PHP (Personal Home Pages), ASP (Active Server 
Pages), ASP.NET şi JSP (Java Server Pages). La acestea se mai adaugă si o serie de alte 
tehnologii de interes mai restrâns. 
Cursciristicle generale ale paginilor Web dinamice generate pe partea de server, 
indiferent de limbajul de scripting folosit sunt: x 4 
- este necesar un procesor pentru paginile dinamice sau un mediu de execuţie; 
- intro pagină de script (ASP, JSP, PHP) pot fi îmbinate limbajul HTML şi secvenţe 
o pd, n "me " 
= secvențele de cod sunt executate pe partea de server, înainte de a trimite pagina la 
client; E AM 
- există astfel posibilitatea de a particulariza paginile în mod dinamic; 
- oferă posibilitatea de interacțiune cu baze de date diferite; 
= au acces la toate resursele serverului Web (fişiere, reţea). A 1 
În mod uzual prin intermediul scripturilor sunt prelucrare informațiile din câmpurile 
formularelor («FORM») din cadrul paginilor Web. 
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16.3. Limbajul de scripting PHP 


PHP (acronim pentru "PHP: Hypertext Preprocessor") este un limbaj de scripting de 
uz general, cu cod-sursă deschis (Open Source), utilizat pe scară largă, şi care este potrivit în 
special pentru dezvoltarea aplicaţiilor Web şi poate fi integrat în HTML. PHP este la ora 
actuală cel mai răspândit limbaj de scripting open-source fiind folosit de milioane de site-uri 
de pe mapamond. 

PHP a fost început în 1994 ca o extensie a limbajului server-side Peri, şi apoi de o 
serie de CGl-uri compilate de către Rasmus Lerdorf, pentru a genera un curriculum vitae şi 
pentru a urmări numărul de vizitatori ai unui site. Apoi a evoluat in PHP/FI 2.0, dar proiectul 
open-source a început să ia amploare după ce Zeev Suraski si Andi Gutmans, de la Technion 
au lansat o nouă versiune a interpretorului PHP în vara anului 1998, această versiune primind 
numele de PHP 3.0. Tot ei au schimbat şi numele în acronimul recursiv de acum, până atunci 
PHP fiind cunoscut ca Personal Home Page Tools. Apoi Suraski si Gutmans au rescris baza 
limbajului, producând astfel si Zend Engine în 1999, În mai 2000 a fost lansat PHP 4.0, având 
la bază Zend Engine 1.0. Pe 13 iulie 2004 a fost lansat PHP 5, cu Zend Engine II, ce a adus si 
o orientare obiect mai pronunțată şi suportând mai multe caracteristici ale acestui tip de 

PHP este simplu de utilizat, fiind un limbaj de programare structurat, ca şi C-ul, Perl- 
ul sau începând de la versiunea 5 chiar Java, sintaxa limbajului fiind o combinaţie a celor trei. 
Datorită modularităţii sale poate fi folosit si pentru a dezvolta aplicaţii de sine stătătoare, de 


exemplu în combinaţie cu PHP-GTK sau poate fi folosit ca Perl sau Python în linia de — — 


comandă. Probabil una din cele mai importante facilităţi ale limbajului este conlucratea cu 

majoritatea bazelor de date relational, de la MySQL şi până la Oracle, trecând prin MS Sql... 

Server, PostgreSQL, sau DB2. -— 
PHP poate rula pe majoritatea sistemelor de operare, de la UNIX, Linux, Windows, 

sau Mac OS X şi poate interacţiona cu majoritatea serverelor web. Codul dumneavoastră PHP 

este interpretat de serverul WEB şi generează un cod HTML care va fi văzut de utilizator 

(clientului -browserului- fiindu-i transmis numai cod HTML). 

"He Un exemplu de script php, poate fi observat mai jos(clasicul "Hello World"): 

«? 

+ comentariu pe o singură linie 

// comentariu pe o singură linie 

/* 


comentariu pe 

mai multe linii 

se pot comenta linii de cod php 
echo 'acesta este un echo comentat’; 
echo 'Buna ziua’; 

Ld 


16.4. Limbajul de scripting ASP 


Tehnologia Active Server Pages (ASP) dezvoltată de Microsoft permite realizarea de 
scripturi pentru server şi este folosită pentru crearea şi rularea în mod dinamic a aplicaţiilor 
Web server interactive. 
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Cu ASP se pot combina pagini HTML, comenzi de script si controale ActiveX pentru 
crearea de pagini Web interactive sau aplicaţii Web complexe. Când serverul primeşte o 
cerere pentru un fişier ASP, prelucrează scriptul conținut în fişier pentru a construi pagina de 
Web care este trimisă apoi la navigator. 

ASP oferă totodată posibilitatea de a stoca informaţia dintr-un formular HTML într-o 
bază de date, de a personaliza site-uri Web, oferind diverse opţiuni pentru vizitatorii site-ului 
sau de a folosi diferite caracteristici HTML bazate pe navigator. 

Pentru a prelucra un formular HTML pe server, ar trebui utilizat limbajul Perl sau C 
pentru construirea unui CGI convenţional. Cu ASP se poate prelua informaţia dintr-un 
formular HTML care va fi stocat într-o bază de date, folosind numai scripturi simple înglobate 
în documente HTML. 

ASP este proiectat independent de limbaj, deci se poate utiliza orice limbaj pentru care 
există instalat un compilator ibil COM. ASP are înglobate limbajele VBSscript si 
JScript., dar se pot instala şi compilatoare pentru limbajele Perl, Rexx sau Python. 

“Totodată, ASP oferă o cale flexibilă pentru a crea pagini Web si de a dezvolta aplicaţii 
Web într-un limbaj de programare ca Visual Basic, C++ sau Java. Se poate include si o siglă a 
aplicaţiei în module care vor fi apelate si executate de către alte componente sau programe. 

Un script pentru server începe să se execute atunci când un program de navigare 
solicită un fişier ASP de pe server. La rândul său, serverul apelează ASP-ul care prelucrează 
fişierul solicitat şi execută fiecare comandă din script, după care trimite pagina câtre 

ramul de navigare. 
vr Deoarece scie se execută mai mult pe server mal pui pe client, Med vn 
responsabil pentru generarea paginii HTML trimisă către program navigare, În acest fel, 
muta scriptor mu poate fi copiată (furată), deoarece la client (programul de navigare) 
ajunge numai rezultatul scriptului, iar utilizatorul mu poate să citească comenzile scripturilor 
ina. 

is n en ASP se creează de fapt în VBScript sau în JavaScript. Indiferent de 
limbajul folosit, navigatorul procesează scripturile identic, rezultatul HTML. formatat fiind 
SM in de tai simple, ASP poate crea aplicaţii complexe, cum sunt colectarea şi 
procesarea informaţiilor de comandă în aplicaţii de comerț electronic. | : wea 

Un fişier ASP este un fişier text cu extensia (asp), ce confine orice combinaţie a 
următoarelor elemente: text, marcatori HTML, comenzi de script ASP. — 

Dacă se doreşte adăugarea unor scripturi la o pagină HTML, mai întâi va trebui să se 
redenumeascá fişierul, atribuindu-i extensia (.asp). Pentru a-l face accesibil utilizatorilor Web, 
este necesară activarea permisiunii de script sau de execuţie pentru directorul unde se află 

respectiv. 
fierul epe area fişierului ASP se poate folosi orice editor de text dar este preferat un 
mediu cu suport pentru ASP cum este Microsoft Visual Studio sau Macromedia 

Un script este constituit dintr-o serie de comenzi sau instrucţiuni. Faţă de marcatorii 
HTML care formatează un text sau prelucrează un format de imagine, de video sau de sunet, 


primare. Aceste comenzi 
sunt procesate folosind un limbaj de script primar. Limbajul implicit este VBScript, dar poate 
fi folosit orice limbaj de script pentru care este instalat un compilator. 
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Între delimitatorii ASP se poate include orice expresie, structură, procedură. sau 
operator valid pentru limbajul de script respectiv. 

„ASP permite creatorului de pagini Web să scrie proceduri prin folosirea mai multor 
limbaje de script. Deoarece fişierele (.asp) sunt interpretate pe server, navigatorul clientului 
nu trebuie să aibă suport pentru scripturi. 

„ASP are inclus două motoare de scripting: Microsoft Visual Basic Scripting Edition 
(VBScript)-implicit si Microsoft JScript, dar se pot instala motoare si pentru alte limbaje. 

În tabelul 16.1 sunt prezentate principalele caracteristici ale limbajelor VBScript şi 
JScript, dintre care o parte vor fi detaliate în continuare. 


Tabelul 16.1. Caracteristici ale limbajelor de script 


VBScript | JScript 
g H 

NU DA 
Dim var 
Const vart 


VBScript nu este case sensitive, astfel că un cuvânt scris cu majuscule are aceeași 
semnificație dacă este scris şi cu minuscule. De exemplu, Request şi request se referă la același 
obiect ASP (Request). Jscript este case sensitive, deci scrierea unui cuvânt cu caractere 
majuscule sau minuscule influențează semnificația acestuia. 

Declararea unei variabile echivalează cu rezervarea unei locaţii de memorie în care se 
va introduce o dată (un număr sau un text). Data introdusă în variabilă reprezintă valoarea 
variabilei, , 

VBScript nu necesită declararea unei variabile înainte de utilizare, dar este 
recomandată efectuarea ei. În acest scop se folosesc cuvintele cheie: Dim, Public sau 
Private. 

Cu <% Dim UserName 26» se declarată o variabilă de tip variat, adică 
poate să conţină orice tip de dată. 

Dacă la începutul fişierului (asp) s-a introdus comanda Option Explicit, atunci 
declararea variabilelor VBScript devine obligatorie. 

În JScript declararea variabilelor este impusă numai pentru variabilele locale din 
proceduri, dar este recomandată declararea oricărei variabile înainte de folosire. Pentru 
declararea unei variabile se foloseşte cuvântul cheie var: 

<% var UserName; %> 

Alături de variabile locale şi globale, se pot declara variabile după domenii: variabile 
de sesiune şi variabile de aplicaţie. Variabilele globale sunt accesibile numai pentru o singură 
pagină (asp). O variabilă având domeniul de sesiune este accesibilă pentru toate paginile 
dintr-o aplicaţie ASP rulată de un client. Aceste tipuri de variabile sunt utile pentru stocarea 
de informaţii pentru un singur client; de exemplu, preferinţele sau numele clientului respectiv. 
O variabilă având domeniul de aplicaţie, este accesibilă pentru toate paginile dintr-o aplicaţie 

ASP rulată de orice client. Pentru a declara o variabilă cu domeniu de sesiune, se foloseşte 
obiectul Session în care se va salva numele şi valoarea variabilei. De exemplu, în următorul 
script sunt salvate valorile a două variabile de sesiune Nume şi Prenume: 
<% 
Session ( "Nume ”) = "Popescu" 
Session ( ”' Prenume ") = "Ionel" 
%> 


Pentru accesarea variabilei cu domeniu de sesiune se foloseşte tot obiectul Session: 
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<% |f Session "Prenume")- "Ionel” Then 9% > Ativizitat deja 
pagina. 

<% Ehe % > 

Este prima vizita in aceasta pagina. 


<% Endlf9» ? 
Pentm a declara o variabilă cu domeniu de aplicaţie, se foloseşte obiectul 
Application, incare seva salva numele şi valoarea variabilei. De exemplu: 
< 96 Application ("salut") = "Ozi bună 1" % > 4 
O constantă este alcătuită dintr-un identificator ce înlocuieşte un număr sau un sir 
de caractere. Unele componente ASP cum sunt ActiveX Data Objects (ADO), definesc 
constantele care pot fi folosite în scripturi; declararea constantelor se realizează in 
componenta type library constituită sub forma unui fișier în care se regăsesc informațiile 
privind obiectele şi tipurile acceptate de o componentă ActiveX. - 
Pentru a declara tipul bibliotecii se foloseşte marcatorul <METADATA> în fişierul 
Global al aplicaţiei. y > 
În NBScript declararea constantelor se efectuează cu directiva Const, iar in JScript cu 
directiva var. — Boat T 1 
Paginile ASP pot utiliza câteva directivele care nu aparţin limbajului de script propriu 
zis. Ele se împart în două categoi directive de ieşire şi directive de procesare. y : 
Directivele de ieşire au rolul de a afişa valoarea unei expresii specificate între 
delimitatori; sunt de forma: x 
<% =expresie %> 
O directivă de ieşire este echivalentă practic, cu o comandă Response. Write. 
Directivele de procesare furnizează informaţii privitoare la modalitatea de procesare a 
fişierului (.asp). Formatul unei directive de procesare este: 
«96 @ cuvánt, cheie 96» ia MER. 
Directiva de procesare «26(2) LANGUAGE - VBScript. %> setează VBScript. ca limbaj 
de script implicit pentru pagină. Directiva trebuie să apară in primul rând al fişierului (asp). 
Observaţie: nu se pot specifica directive de procesare într-un fişier (asp) inclus cu 
directiva Hinclude. y^ a 
Cuvintele cheie ce se pot utiliza în cadrul directivelor de procesare sunt: 
LANGUAGE - setează limbajul de script implicit al paginii; 
CODPAGE - seteazh pagina de cod a paginii ASP; 
LCID — setează identificatorul local al paginii; e) 
TRANSACTION — verifică dacă pagina va rula în context tranzacjional; y 
ENABLESESSIONSTATE - arată dacă se va activa modul sesiune pentru pagina 
respectivă. i UN , 
Ca orice limbaj de programare, VBScript şi JScript pun la dispoziţie structuri 
fundamentale de programare. Exemplul următor utilizează o structură altemativă 
Vf... Then... Else în VBScript: 


<% 

If Time >=#06:00:00 AM And Time< #20:00:00 PM 
Then 

Else 

salut=” O zi bună 1" 

salut= „ Noapte bună !„ 

End lf 

p 

<% = salut 96» 
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În funcție de ora la care se solicită execuția, rezultatul ce se afişează va fi „O zi bună 
1" sau „ Noapte bună ! „. Comanda <% = salut %> trimite valoarea variabilei salut către 
navigator. 

Comenzile ASP pot fi intercalate cu text HTML. În exemplul anterior, se poate realiza 
acelaşi lucru în felul următor: 


<% Jf Time> = 06:00:00 AM# And Time< $20:00:00 PM: Then 96» 
Ozi bună ! 

<HElse%> 

Noapte bună ! 

<% End f %> 


16.4.1. Crearea obiectelor 


Cheia dezvoltării aplicațiilor Web complexe sunt componentele ActiveX. Ele 
furnizează obiectele care se folosesc în scripturi pentru scopuri diverse. 

O componentă ActiveX este un fişier care conține instrucțiuni pentru realizarea unui 
anumit program specific. Componentele sunt reutilizabile. Odată ce s-a instalat o 
componentă pe un server Web, ea poate fi apelată dintr-un script ASP, dintr-o aplicație 
ISAPI, dintr-o altă componentă sau dintr-un program scris într-un alt limbaj compatibil 
COM. 

O componentă este un program: executabil conținut într-un fişier cu extensia „dl! 
(dynamic link library) sau .exe. O componentă poate instanția obiecte, iar prin obiecte se pot 
accesa proprietăţile şi metodele. 

Instanţierea unui obiect se face cu metoda ASP Server. CreateObject care returnează 
referința către obiectul creat, referinţă ce trebuie păstrată într-o variabilă. 

În ASP, pentru crearea obiectelor nu se foloseşte funcţia limbajului de script 
(CreateObject în P VBScript şi New in Jscrip). Exemplul următor creează o instanță a 
componentei AdRotator. 

<% Set My4ds = Server.CreateObject (“MSWC.AdRotator ") %> 

Obiectele se pot crea şi prin intermediul marcatorului HTML «OBJECT»: 
<OBJECT  RUNAT=Server ID=My4d  PROGID="MSWC.AdRotator "> 
</OBJECT> 

ASP are câteva obiecte incluse, ce conțin datele trimise spre server de către 
formularul HTML. Aceste obiecte nu trebuie instanțiate, ele pot fi folosite direct in 
scripturi. 
Obiectul Application se foloseşte pentru a partaja informaţiile către toți clienții unei 
aplicații. 

Obiectul Request A folosit pentru a accesa orice informații trimise printr-o cerere 
HTTP. Aceste informații pot 

- parametri trimişi rude -un formular HTML prin metoda POST sau GET, 
* cookie-uri; 
- alte certificări ale clienţilor. 

Obiectul Request face totodată posibilă accesarea informaţiilor trimise sub formă 
binară, cum sunt transmisiile de fişiere. 

Obiectul Response controlează informaţiile transmise către client. Controlul include 
transmiterea de informaţii direct către navigator, redirectarea navigator-ului către un alt URL 
sau setarea unor valori cookie. 


Trimiterea de text HTML către navigator se poate realiza şi prin intermediul 
comenzilor de script, situaţie în care se va folosi obiectul Response. Exemplul anterior poate fi 
realizat astfel: 

«96 

If Time >=#06:00:00 AM$ And Time< 320:00:00 PM* Then | 
Else 

Response. Write “ O zi bună !” 

Response. Write “ Noapte bună !" 

EndIf 

%> 


Funcția Write a obiectului Response are rolul de a trimite textul către navigator. 

Obiectul Server asigură accesul la metodele şi proprietăţile de pe server. Cea mai 
folosită metodă este aceea care instanțiază o componentă ActiveX (Server. CreateObject). 
Alte metode sunt codificarea URL sau HTML a şirurilor de caractere, maparea căilor 
virtuale în căi fizice sau setarea perioadei de timeout pentru un script. 

Obiectul Session se utilizează pentru a păstra informații pentru o sesiune particulară. 
Informaţiile din obiectul Session nu sunt pierdute cât timp utilizatorul se plimbă printre 
pagini, ele persistând de lungul accesări paginilor aplicației de către client. 

Obiectul ObjectContext se foloseşte pentru a realiza sau abandona o tranzacție 
de un script ASP. 

Se pot defini şi obiecte proprii in Jscript, prin crearea unei funcții constructor care 
creează şi inijializeazà proprietăţile şi metodele unui obiect nou. Obiectul este instanjiat când 
în script se utilizează operatorul new care apelează constructorul. Dacă obiectele JScript 
sunt definite cu domeniu de sesiune sau de aplicaţie, atunci nu pot fi accesate metodele 
lui. 


ifiata. 


Când este prelucrat un script ASP, orice text în afara delimitatorilor ASP sau a 
marcatorilor «SCRIPT» este returnat către navigator. Informaţiile către navigator pot fi 
trimise explicit prin obiectul Response, metoda Write. 


16.5. Exemplu de lucru cu baze de date online 


Pentru a putea realiza un script ASP trebuie să avem umătoarele: 

- Un calculator pe care să fie configurat un server de web(ex. Internet Information 
Server). Orice sistem Windows poate fi uşor configurat să suporte scripturi ASP. 

- Un editor. Putem folosi Wordpad sau editoare specializate cum este Macromedia 
Dreamweaver. 

- Un browser web cu care să vedem rezulatul execuţiei scriptului. 

Având în vedere că scripturile ASP sunt realizate de obicei pentru a lucra cu baze de 
date putem spune că avem nevoie şi de o bază de date pentru a executa scriptul. Aceasta 
trebuie să fie pe același calculator cu scriptul, preferabil în același director. Spre exemplu 
baza de date din figura 16.3 care confine o singură tabelă numită “studenţi“ si este realizată în 
Microsoft Access. Ea conţine o listă de studenți care au susținut un anumit examen: 

Vom realiza un script ASP care afişează aceşti studenți. Scriptul ASP realizat de noi 
va fi unul minimal şi va realiza trei operaţii: 

- Conectarea la baza de date. Este o operaţie care se realizează de către sistem, 

utilizatorul fiind responsabil doar pentru furnizarea parametrilor de 
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conectare(denumire bază de date şi dri intra în detalii 
, acea pate ji rugă cita să ia sevena decod ati Ie ali Ice de 
eges pezei de date. Se mealizeazā în limbajul SQL (Standard Query 
„. Language) si so fce în baza unei cereri SQL construite de realizatorul scriptu 
lucrarea informaţiilor returnate de cererea de căutare si afişarea lor. vei 


Rx EVI 
Fig. 16.3. Tabela Studenţi 


Se observă ca secvențele de cod ASP cesta 
e sunt marcate cu <% ...96». În feh 
- E 
rverul poate să le recunoască si să le ruleze. Ele sunt plasate printre secvenţe é em 


care sunt ignorate de int i imi ^ 
pralno. erpretorul ASP şi sunt trimise mai departe spre browser fară nici o 


«html 

<head> 

<title>Scriprul meu</title> 

</head> 

<body> 

//Se creaza obiectul “server” 

set myconn = server.createobject("adodb.connection") 


//Se presupune ca baza de dat 
Coriolan udat batina” din eul A 


dbpath = server. mappath("/-cmI901!baza. mea") 
//Secventa de conectare 


connection = "PROVIDER= Microsoft. Jet. OLEDB.4.0;DATA SOURCE=" & dbpath & 
studenti. mdb” 
myconn.open(connection) 
//Interogarea bazei de date 
set result = server.createobject("adodb.recordset") 
sql = "SELECT * FROM studenti" 
set result = myconn.execute(sql) 
//Afisarea rezultatelor 
while not result. EOF 
response.write("«br»" & result("nume")) 
response write("<br>" & result("prenume")) 
response.write("<br>" & result("nota")) 
response.write("«br»" & resuli("grupa")) 
result.movenext() 
wend 
</body> 


</html> 


16.6. Aplicație demonstrativă 


1n cele ce urmează vom prezenta o aplicaţie care gestionează o bază de date. Aplicația 
este o versiune simplificată a clasicelor interfețe web pentru managementul tabelelor, Codul a 
fost scris în mod cu comentarii pentru a permite cititorilor interesați de lucrul cu ASP să Îşi 
rafineze cunogtintele prin rularea ei pe un calculator personal. Tehnologiile folosite sunt ASP 
clasic pentru partea de server-side scripting şi SQL Server ca SGBD. 

Scripturile ASP sunt în numár de şapte şi au functionaltăți specifice administrării 
bazelor de date. Există un script central (default.asp) si o serie de scripturi funcţionale care 
conţin codul ASP propriu-zis. În general, recomandăm cititorilor ca pe parcursul dezvoltării 
scripturilor, să nu se grupeze mai mult de câteva funcţii într-un script, 
urmări cu uşurinţă firul logic al aplicaţiei. 


deoarece astfel se poate 


Default.asp 


«IDOCTYPE HTML PUBLIC "-//IETF/DTD HTML//EN"> 
«html» 


<head> 
<meta http-equiv="Content-Type" content= "text/html; charset=iso-8859-1 "> 


«meta name ="GENERATOR" content="Microsoft FrontPage 6.0"> 
<title>Utilitar online de maintenanta a Serverului SQL«/title» 
</head> 
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«body bgcolor-"éFFFFFF"» 
<font face="Verdana"> 


«center» 
<hI><font color="blue"> Utilitar online de maintenanta a Serverului SOL«/font» «/h17- 


&nbsp:<P> 


«table cellpadding=10 border=2 bgcolor="Aqua" width=300><tr><td> 
<form action="ServerAdmin.asp" method="POST "> 
<table border="0"> 
em 
«th align--"right"»Nume server: «/th» 
«td» «input type="text" size="20" maxlength="256" name--"ServerName" 
value-"«96- Request.ServerVariables(" SERVER NAME")96» "> 
</td> 
<tr> 
<r> 
<th align="right"> Nume de utilizator:</th> 
<td><input type- "text" size="20" maxlength="256" name="Login" 
value "«967 Request.ServerVariables("LOGON. USER")96»"» 
Sd» 
«m 
«m» * Lă 
«th align="right"> Parola: </th> 
<td><input type="password" size="20" maxlength="256" name="Password"> 
«d» à 
<hr> 
<r> 
«td» «/td» «td align=lefi> 
&nbsp; «P» «input type="submit" value "Conectati-va' 
<hd> 


<hr> 
</table> 
</form> 
X/td» «/tr» </table> 


Databases.asp 
«948 LANGUAGE = VBScript 96» 


<HTML> 

<HEAD> 

<META NAME-"GENERATOR" Content="Microsoft Developer Studio" 

<META HTTP-EQUIV="Content-Type” content="text/html; charset=150-8859-1"> 
«TITLE? Baza de date Online</TITLE> 
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</HEAD> 


<HTML> 
«BODY BGCOLOR="aqua" lefimargin-5 topmargin=5> 


<% 
On Error Resume Next 


Jf Not IsObject(Session{"SQLServer")) Then 
Response. Write("Obiectul conexiunii SOL Server mu exista!") 
Response. End 

End lf. 


Dim oSOLServer 
Set oSQLServer = Session("SQLServer") 
96» 


<FORM ACTION-"DBltems.asp" METHOD-"GET" TARGET "dbitems" 
«table» «tr» «td» «B» Baza de date:«/B» «/id» «td» 
«SELECT NAME - "Database" 
«96 
For Each SQLDB In oSQL Server. Databases 
Jf Not SOLDB.SystemObject Then 
Response. Write "<OPTION VALUE-""" & SQLDB.Name & """»" & SQLDB.Name & 
"nbsp; &nbsp;" 
Endlf 
Next 
Set oSQLServer = Nothing 
%> 


</SELECT> 
</td> «td» <INPUT TYPE-"submit" VALUE "Arata!"» «/td» </tr></table> 
</FORM> 


</BODY> 
</HTML> 


Dbitems.asp 
«968) LANGUAGE = VBScript %> 


<HTML> 

<HEAD> 

<META NAME="GENERATOR" Content="Microsofi Developer Studio"> 

<META HTTP-EQUIV="Content-Type" content="text/html; charset-1SO-8859-1'- 
«TITLE» Baza de date Online</TITLE> 

</HEAD> 


«BODY BGCOLOR- fff lefimargin=5 topmargin=5> 
«FONT FACE=Arial> 


<% 
"On Error Resume Next 


If Not IsObject(Session("SOLServer")) Then 

Response. Write("Obiectul conexiunii SQL Server nu exista!") 
Response. End 
Endif 


Dim oSQLServer. 
Set oSQLServer = Session("SQLServer") 


"acum gasim baza de date de care avem nevoie 

Set thisDb = oSQLServer.Databases(CStr(Request(" Database"))) 

Jf Err.Number > 0 Or Not IsObject(ihisDb) Then 
Response. Write("Baza de date nu exista pe Serverul SQL!«BR»" & Err. Description) 
Response.End 

End lf. 


Set Session("ActiveSQLdb") = Nothing 
Set Session(" ActiveSQLdb") = thisDb 
96» 


«H27 «font color "blue" «*6-thisDb.Name?6» </font></H2> 
<A HREF="isql.asp” target="showpane "> «I» Utilitar ISQL«/I» «/A» «P-» 
<B>Tabele</B> 
«font size=-1> 
<UL> 
<% 
For Each DBTable In thisDb. Tables 

If Not DBTable.SystemObject Then 

Response. Write "<LI>" & "<A TARGET=""showpane 

HREF=""DBMap.asp? DBOType=Table&DBObject=" & DBTable. Name & """>" & 
DBTable. Name & "</A>" & Chr(13) 

End |f. 
Next 
96» 
</font> 
</UL> 


<P> 
<B>Viziuni</B> 
«font size=-1> 
<UL> 
<% 
For Each DBView In thisDb. Views 

Jf Not DBView.SystemObject Then 

Response. Write "<LI>" & "<A TARGET=""showpane"" 

HREF=""DBMap.asp? DBOType=View&DBObject=" & DBView.Name & """>" & 
DBView.Name & "</A>" & Chr(13) 

End lf. 
Next. 
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%> 
<font> 
</UL> 


<P> 
<B>Proceduri Stocate</B> 
<font size=-1> 
<UL> 
<% 
For Each DBsp In thisDb.StoredProcedures 

Jf Not DBsp.SystemObject Then 

Response.Write "<LI>" & "<A TARGET=""showpane' erg D mă 

HREF=""DBMap.asp? DBOType=SP&DBObject=" & DBsp.Name & sp, Namu 
& "</A>" & Chr(13) 

End 
Next 
%> 
</font> 
</UL> 
<P> 


<% 
Set oSOL Server = Nothing 
96» 


</BODY> - 
</HTML> 


Dbmap.asp 
<%@ LANGUAGE = VBScript %> 


<HTML> 

<HEAD> 

«META NAME="GENERATOR" Content="Microsoft Developer Studio" ^ 
«META HTTP-EQUIV - "Content-Type" content="text/html; charset-180-8859-1'» 
«TITLE» Baza de date Online</TITLE> 

</HEAD> 


«BODY BGCOLOR-ffff lefimargin=5 topmargin=5> 
«FONT FACE=Arial> 


<% 
On Error Resume Next 


If Not IsObject(Session("ActiveSQLdb")) Then = 
pei ir a fost stabilita nici o conexiune cu baza de datel") 


Response.End 
End If 
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am mn 


Dim thisDb 
Set thisDb = Session("ActiveSQLdb") 


Select Case Request("DBOType") 
Case "Table" ? 
Set theTable = thisDb Tables(CStr(Request(" DBObject" 
Af Err.Number > 0 Then ROREM ci 


Response. Write("Tabela nu exista in baza de date! -BR»" & Err. 
Response. End ici 
Endlf 

PrintTable theTable 

Set theTable = Nothing 


Case "SP" 
Ser theSP = thisDb.StoredProcedures(CStr(Request("Di ") 
Pn AR ayt ei '("DBObject"))) 


Response. Write ("PS nu exista in baza de date! -BR»" 

Fiat Ie BR?" & Er. Description) 
End If 
PrimSP theSP. 
Set theSP = Nothing 


Case "View" 


Set theView = thisDb, Views(CStr(Request("Di ") = 
I Err.Number > 0 Then ense 


Response. Write("Viziunea nu exista in baza de «BR»" 
Reone Wr n date!<BR>" & Err. Description) 
End 

PrintView theView 

Set theView = Nothing 


Case Else 
Response. Write("Actiune selectata non valida!") 


End Select 


Set thisDb = Nothing 
9» 
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idee An Then 
jot thisSP.: bject 
5 PI CENTER> cH3* & ihsSP. Name & "procedura 
jocata</H3> «CENTER» " 
ge Write "<TABLE BORDER=1 WIDTH-""8096""» «tr» «id» " 
Response. Write "<PRE>" & thisSP. Text & "</PRE>" 
Response. Write "«/td» «Ar? «/TABLE»" 
End If 
End Sub 
Sub PrintTable(thisTable) 
Jf Not thisTable.SystemObject Then 
HasDef = False t 
Response.Write "<CENTER><H3>" & thisTable.Name & 'tabela</H3> «CENTER» 
Response. Write "<TABLE BORDER-1 WIDTH=""80%""> 


Response. Write E 
"eir «th» Namec/th» «th» Datatype «/th» «th» Length</ih> «th? Indexinfo</th> </tr>" 


For Each DBField In thisTable.Columns 

Indexed = False 

abend TH WIDTH «""3596"7- 

Response.write "«TR7«TI am3596"n" F 

Taani ula DBField Name & "</TH> «TD. WIDTH-""1596 2^ A 

Response.write DBField Datatype & "</TD><TD WIDTH=""15% al 
write DBField Length & "</TD><TD WIDTH=""15%""> 

If DBField InPrimaryKey Then 

PK = True 


Else 
PK = False 
End If 


If DBField AllowNulls Then 
Nulls = True 


Else 
Nulls = False 
End 


DefID = dbfield default 


<SCRIPT RUNAT-SERVER LANGUAGE VBScript 


Sub PrintView(thisView) 
TNR this deu SystemObject Then 
sponse. Write "CENTER? «H3»" & thisView. Name & " viziune«/H3» «CENTER» " 

Response. Write "<TABLE BORDER-1 PIDTH=""80%"*> «tr» «id» " = 
Response. Write "<PRE>" & thisView. Text & "</PRE>" 
Response. Write "«/td»«/tr» /TABLE»" 

End 

End Sub 
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DefID = Mid(DefID, 5, Len(Def1D)) 
For Each DBDefault In thisDb.Defaults 


Jf DefID = DBDefault.Name Then 
DefArray(l, 0) = thisTable.Name 
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For Each DBindex In thisTable. Indexes 
Jf DBindex. Name = DBField Name Then 
Indexed = True 


Jf PK Then 
Response.write "Cheie & Indexat " 
Else 
Jf Indexed Then 
Response.wrile "Indexat " 
End lf 
End |f. 
Jf Not Nulls Then 
 Response.write "Not Null" 
End lf. 
If HasDef Then 
Response.write "<EM>("& I & ")</EM>" 
HasDef = False 
End |f. 
Response.write "&nbsp«/TD» «/TR»" 
Next 
Response.write "/TABLE» «BR» «BR»" 
End If. 
End Sub 


</SCRIPT> 


</BODY> 
</HTML> 


Isqlasp 

<%@ LANGUAGE = VBScript %> 

<HTML> 

<HEAD> 

<META NAME="GENERATOR" Content="Microsofi Developer Studio" 

<META HTTP-EQUIV="Content-Type" content="text/html; charset=IS0-8859-1"> 
<TITLE> Baza de date ISOL Online</TITLE> 

</HEAD> 


<BODY BGCOLOR- éfffff lefimargin-10 topmargin=10> 
«FONT FACE - Arial 


<% 
"On Error Resume Next 


If Not IsObject(Session("ActiveSQLdb")) Then 
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Response. Write("Nu a fost stabilita nici o conexiune cu baza de date!") 


Response. End 
End ff 


Dim thisDb 

Set thisDb = Session("ActiveSQLdb") 

96» 

<center> 

«H2» «font color="blue "><%=thisDb.Name%> </font> - Utilitar ISQL</H2> 


<% 
If Len(Request("isglhtm"))70 Then 
Select Case Request("isgltype") 
Case "nores" 
thisDb. ExecuteImmediate Request("isglhtm") SQLOLEExec Default 
Case Else 
Ser gryResults = thisDb.ExecuteWithResults(Request("isglhim")) 
End Select. 


nColNumbers = qryResults.Columns 

Response. Write "<TABLE BORDER I» <TR>" 

For i=] To nColNumbers 1 
Response. Write "«TH»" & Server. HTMLEncode(qryResults. ColumnName(î)) & "«/TH» 

Next 

Response. Write "</TR>" 


nRowsToReturn = qryResults. Rows 
Jf nRowsToReturn > CLng(Request("isqlrows")) Then nRowsToRerum = 
CLng(Request("isglrows")) : 


For i=] to nRowsToReturn 
Response. Write "<TR>" 
For j=1 to nColNumbers 
Response. Write "<TD>" & Server. HTMLEncode(gryResults.GetColumnString(i,j)) 
& "</TD>" & Chr(13) 
Next 
Response. Write "</TR>" 
Next 
Response. Write "</TABLE>&nbsp;<P>" 
Response. Write "Maxim " & qryResults. Rows & " de inregistrari vor fi disponibilel<BR>" 


Set aryResults = Nothing 
Set thisDb = Nothing 

%> 

<P> 

Inapoi la ecranul principal <A 

HREF="<96= Request. ServerVariables("SCRIPT_NAME")%>">ISOL</A>! 


<% Else %> 


455 


Capitolul 16, 


Ei 


«table border=0> 
<tr><td> 


<FORM ACTION="< %=Request. Server Variables("SCRIPT_NAME")26>" "y 
<TEXTAREA cols=90 rows-20  NAME-"isglhtm"7 Select *, from ? ina i-a 


rablename</TEXTAREA><BR> 
fid er 
«Ir? «td» &nbsp; «BR» 


*i pee type Bess name-isgltype value="nores"> Fara rezultate 

<input type=radio CHECKED name=isgltype value="res"> Reti 

nbsp; Numarul maxim de linii de returnat: TE Hg tits 
input typetext name7isglrows value="25"><P> 


<input type=submit value="Ruleaza!"> 
</FORM> 

<Ad></tr></table> 

<% End f %> 


</center> 
<P> 


<P ALIGN=right><font size=1>&copy; 2007 Crystal-System</font>-</P> 


</BODY> 
</HTML> 


Serveradmin.asp E 
x94) LANGUAGE = VBScript %> 
<HTML> 


<HEAD> 
<META NAME="GENERATOR" Content= 


"Microsoft Developer Studio" > 


<META HTTP-EQUIV="Content-Type" content="text/html; charset- 

ŞIITLE> Administrare Online a bazei de date penru EAR ES 
< Request. Form("Servername")%> 

Peter me")96> </TITLE> 


<% 
On Error Resume Next 
Dim oSOLServer 


Set oSOL Server = CreateObject ("SQLOLE SQLServer") 


Set Session("SOLServer") = Nothing 
Af Err.Number > 0 Then 


Response. Write("SOLOLE nu a putut fi initializat! <BR>" & Err. Description) 


Err.Clear 
Response. End 
End 


strServer = Request. Form("ServerName") 
strLogin = Request.Forn("Login") 
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strPwd = Request. Form("Password”) 
oSQLServer.Connect strServer,strLogin,strPwd 


Jf Err.Number > 0 Then 
Response. Write("Conexiune nereusita cu Serverul SQL!«BR»" & Err. Description) 


Err.Clear 
Response. End 
End lf. 


Set Session" SOLServer") = Nothing 
Ser Session(" SOLServer") = oSQLServer 
Set oSQLServer = Nothing 

p 


«FRAMESET FRAMEBORDER -"0" FRAMESPACING "0" COLS="300,*"> 
«FRAMESET FRAMEBORDER "0" FRAMESPACING "0" ROWS "50, *"> 
«FRAME MARGINWIDTH="2" MARGINHEIGHT "0" SRC-"Databases.asp" 


NAME "databases" NORESIZE SCROLLING="no"> 
«FRAME MARGINWIDTH="2" MARGINHEIGHT="0" SRC="pane1.htm" 


NAME-"dbitems" NORESIZE SCROLLING "auto" 


</FRAMESET> 
«FRAME MARGINWIDTH="10" MARGINHEIGHT "5" SRC«"emptypage.htm" 


NAME - "showpane" z 
</FRAMESET> 


«BODY BGCOLOR - Hffffjf topmargin=0 lefimargin=0> 
«Font face Verdana 


Frames required! 


</BODY> 
</HTML> 


Paginile HTML statice. In aplicaţie sunt incluse şi două pagini statice scrise în cod 
HTML care sunt necesare pentru buna funcționare a site-ului. 


panel.html 


<HTML> 
<HEAD> 

«META NAME="GENERATOR" Content="Microsoft Developer Studio" 

<META HTTP-EQUIV "Content-Type" content- "text/html; charset=IS0-8859-1"> 
«TITLE» Online Database</TITLE> 

</HEAD> 


«BODY BGCOLOR-&ffflf lefimargin-5 topmargin-5» 
«FONT FACE=Arial> 


<H2><font color ="blue "> Numele bazei de date</font></H2> 
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<B> Tabele</B> «font size=-1> 
<UL> 

«LI»primul tabel</font> 
«UL» 


<P> 

<B>Proceduri Stocate</B> 

«font size=-1> 

<UL> 

«LI»prima procedura stocata </font> 
</UL> 

<P> 


</BODY> 
</HTML> 


Emptypage.html 


<HTML> 
<HEAD> ~ 

<TITLE> Baza de date Online</TITLE> 
</HEAD> 


«BODY BGCOLOR -4fffrr- 

S  face=Arial> Pasii necesari pentru a vizualiza baza de date SOL 

<OL> 

<LP> Selectati o baza de date <LI>Sele 

Tabea 2 MER lectati un obiect al bazei de date (momentan doar 
«oL» 

<A HREF="! htm". =" top». 

Buca "Information. larget" top"» Informatii</4> suplimentare. 

</HTML> 
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